A PDF is easy to file away without reading. That is a mistake when the document will support a payment decision. An A2 Route report records a screening result and its context. It does not certify the wallet owner or guarantee acceptance of the funds. Read the fields in order, then write your business decision separately. This walkthrough follows the committed synthetic sample reports linked from the product page.
Start with the sample's scope
The public examples are transaction screening reports with a main page and a risk-categories appendix. The REVIEW example concerns an outgoing transfer and discusses the destination address. The ALLOW example concerns an incoming transfer. They illustrate the report layout, not real customers or registered checks. Do not generalise their fixture values into product thresholds.
Open the samples from the report section. Any identifiers in those PDFs are synthetic. In your own training notes, use deliberately invalid labels such as FAKE_WALLET_NOT_AN_ADDRESS and FAKE_TRANSACTION_NOT_A_HASH. Do not substitute real public wallets into an example. The instructions below are for reading fields, not submitting demonstration identifiers.
1. Subject
First confirm the network, direction, asset, amount, transaction hash, sender and recipient. Check the screening time and check ID against the trade record. A perfectly readable result for the wrong subject is not useful evidence for your payment. If an address-mode explanation appears, read it before interpreting the exposure shares.
The sample's sender line can show activity and balance information with a stated source. Treat it as reported context, not identity verification. In an outgoing report, distinguish the account holder's funds being sent from the destination wallet being assessed. The sample's source-of-funds summary explicitly makes that distinction.
2. Payment reference
The next section contains client-provided payment-reference fields: prepared for, invoice or contract, and purpose of payment. Their presence does not mean the screening service verified the underlying documents. Compare them with your own records. If the invoice reference is wrong, correct the trade file rather than assuming a polished PDF makes it authoritative.
Keep the distinction when forwarding the report. “Client-provided purpose” and “verified purpose” are different claims. The limitations section says purpose of payment is not verified. A report attached to an invoice can document a screening step without proving the invoice's commercial substance.
3. Why this verdict
Read the verdict and score alongside the explanation. The synthetic examples show ALLOW and REVIEW, with reasons and recommendations appropriate to their fixtures. They are not universal instructions for accepting or rejecting payments. Do not copy a sample's threshold into your business procedure.
The REVIEW sample distinguishes an indirect provider-flagged exposure from sanctions-list results showing no match. Preserve that distinction in your notes. The risk-score guide explains why a score is not a probability of wrongdoing. If the explanation does not match the subject you intended to check, stop and verify the ticket details.
4. Sanctions and issuer restrictions
Read each row's list, result and coverage time. The sample includes rows for OFAC SDN, the EU consolidated list, the UK OFSI list and the Tether freeze list. This describes the sample's layout, not a promise that every future check has identical coverage. A no-match row is a result for the stated screening context, not proof that a counterparty has no other risk.
If the surrounding explanation mentions a sanctions-associated provider label, do not rewrite it as a direct list match. Category labels and list results answer different questions. The exposure guide helps separate those meanings before you contact a counterparty.
5. Where the funds come from
This section presents source shares and top exposure, with category, hop, share and amount fields in the sample. Read the accompanying mode explanation. In the outgoing sample, address-mode shares describe the destination wallet's traced incoming funds. They do not say that the same fraction of your proposed outgoing payment has that provenance.
Do not add unrelated percentages across sections or infer a tracing scope the report does not state. Read the appendix and the data-sources methodology when interpreting categories. If a share or amount is unavailable, keep that limitation visible rather than supplying your own estimate.
6. Scope, limitations and integrity
Read the stated sources, mode and limitations. The sample says beneficial ownership, off-chain counterparty identity and purpose of payment are not verified. It also notes that labels can change. A report records evidence at a time; it does not give permanent approval to a wallet.
The public pages say paid reports return a file SHA-256 through the API for lookup at /verify. The linked sample PDFs are not registered checks. A fingerprint comparison concerns file integrity, not the commercial legitimacy of a payment. Keep the original report with the invoice, payment details and reviewer decision.
Turn the reading into a decision record
Note what was checked, what raised concern, what remains unknown and who decided the next step. If coverage is partial, the public FAQ recommends a re-check. For a held trade, use the flagged-wallet checklist. For a separate supplier payment, see the A2vanta business payment blog.
If someone outside the team needs the record, use the bank and auditor packet checklist. For a path involving a mixer label or a customer-described bridge, read the evidence interpretation guide before summarising it.
Start a supported A2 Route check or read the API documentation. The report remains an informational tool, not legal advice, a guarantee of clean funds or a promise of regulatory compliance.