Skavio Payment Proof: Separate Transfer Evidence from a Tax Invoice
Clear USDC payment evidence helps a finance team establish what moved on-chain without confusing that finding with invoice validity. Skavio Payment Proof is a separate, noncustodial payment-confirmation and evidence product: payments go directly to the merchant’s receiving wallet, and Skavio does not require wallet private keys. Use its evidence within three distinct checks—verify the transfer, reconcile the business obligation and review the invoice under applicable tax rules.
1. Verify the token transfer—not just a successful transaction
A transaction hash is a starting point, not a complete payment conclusion. Ethereum transaction receipts expose execution status and logs; ERC-20 Transfer events identify token sender, recipient and amount. A successful transaction alone therefore does not establish that the expected USDC reached the expected wallet. First identify the network and check the token contract against Circle’s official USDC address list, rather than trusting a token name or logo. Then inspect the relevant transfer evidence. For a Base transfer, record the observed confirmation or finality stage: Base documents progressively stronger stages, so an initial confirmation should not be described as final at every later stage. Do not promise a fixed settlement time.
- Record the network, transaction hash and verified USDC token contract.
- Check the token-transfer sender, recipient and amount against the expected payment details.
- Preserve the execution result, relevant transfer event and block reference.
- Record when the check was performed, the observed confirmation or finality state, and any unresolved data-availability uncertainty.
2. Reconcile the transfer to the actual obligation
Once the transfer facts are established, ask a different question: which business obligation does this payment satisfy? An ERC-20 event contains addresses and value, not a customer’s legal identity, an invoice description or proof that a service was delivered. Link the evidence to the invoice or order reference, supporting customer records and the agreed payment terms. If a third party paid, retain the explanation connecting that payer to the obligation. Compare the amount with the amount due and investigate partial payments, overpayments or mismatched references before acknowledging full settlement. A real transfer can still be an internal treasury movement, an owner-funded test or an unrelated payment. Verification does not turn those movements into customer sales. Where the business connection is unresolved, keep that uncertainty visible rather than marking an invoice paid.
3. Review the invoice as a separate document
Skavio Payment Proof’s public interface distinguishes blockchain evidence exports, available as PDF or CSV, from sales invoices. It also presents a separate sales-invoice workflow. These are observations of the published interface, not an end-to-end verification of invoice issuance or generated document contents. The important distinction is that payment evidence does not itself constitute a tax invoice. Tax treatment and valuation inputs remain merchant-supplied, and Skavio does not certify tax compliance. EU VAT example: the European Commission explains that most B2B supplies require an invoice, subject to exceptions. Full VAT invoices include information such as an issue date, a sequential number, supplier and customer details, a description of the supply, pricing and applicable VAT information. Simplified invoices and national rules differ; this is not a complete worldwide checklist. A token-transfer record cannot supply those missing business facts merely because the transfer succeeded. Review the invoice against the rules applicable to the merchant and transaction, using qualified local advice where necessary. Do not treat transfer verification or document generation as confirmation of invoice validity or VAT deductibility.
4. Retain linked records without merging their meaning
Keep the payment evidence and reviewed invoice linked but separately identifiable. A useful handoff includes the transaction reference, the obligation it was matched to, the supporting documents and any unresolved exceptions. The reviewer should be able to distinguish a verified transfer from an accounting or tax conclusion. U.S. recordkeeping example: the IRS calls for sufficient digital-asset records, including USD fair-market-value information for assets received as business payments. Where applicable, retain the valuation source and observation time rather than automatically treating the USDC quantity as the USD accounting value. Use separate review labels to prevent one completed check from silently approving the next. Do not label a transfer verified while the necessary transfer evidence remains unresolved. The following are suggested internal labels—not Skavio product statuses:
- Transfer verified: the expected on-chain transfer facts have been established, with the observed confirmation or finality state and any limitations recorded.
- Invoice matched: the evidence has been reconciled to a specific business obligation, with discrepancies documented.
- Tax review outstanding: invoice requirements, valuation or tax treatment still need review; transfer verification does not resolve them.