Payment Traceability in Accounting: What to Download

A company closes the month and its accountant asks for support behind every payment made in USDC. The question is not abstract: it is which file to download, and whether that file holds up to an auditor or a tax authority in more than one country at once. An on-chain payment does not arrive with a traditional bank statement, so the evidence takes a different shape: a transaction report and a unique identifier attached to every movement. For a company auditing operations that span Colombia, Mexico or another jurisdiction, that difference in shape also means a difference in how each local team files, retains and hands over that evidence.

In Soulbit Academy we explain what that report contains, what document supports each type of transaction, and how to build the audit file for a single operation at month-end close. This is not a reconciliation guide or an IFRS treatment guide: we already cover those two processes in reconcile stablecoin payments in accounting and in accounting for USDC under IFRS. Here the focus is narrower and more operational: what a company downloads, and what is in it.

What payment traceability in accounting means and what on-chain history adds

Payment traceability in accounting is the ability to reconstruct, for every entry, the exact transaction that generated it: its date, its amount, and its supporting record. In a traditional payment, that record is a bank statement or an internal reference number. In a stablecoin payment, it is the on-chain history: every movement is recorded publicly on the blockchain, with a unique identifier and a verifiable timestamp.

Soulbit V1 delivers that full history. Every balance, every inflow and every outflow in USDC or USDT is recorded with its on-chain identifier, available for lookup and for download at any point during the close, not only at month-end. This does not replace the accountant. It gives them the raw material for building entries and working papers.

A company with 40 transactions a month across collections, supplier payments and payroll generates 40 lines of history, each with its own identifier. That volume fits into a single report, exportable in a few steps, without reconstructing each transaction by hand from a network explorer.

The difference from a traditional cross-border banking flow is not only about format. In an international wire that passes through several correspondent banks, the full path of the money is sometimes split across separate institutions, and reconstructing it means requesting records from each one individually. On-chain history, by contrast, is complete from the start, with the same identifier visible to the company, to its accountant and to an external auditor in every country the company operates in.

What the downloadable transaction report contains

The transaction report that Soulbit generates includes, for each transaction in the period, the minimum fields an accounting team needs to build an entry without checking every movement separately on a network explorer.

Report field	What it contains	Use at close
Date and time	The exact timestamp of the transaction	Places the movement in the correct accounting period
Counterparty	Identification of the sender or recipient, per the verified profile	Supports who the collection or payment corresponds to
Gross amount	The amount sent or received before fees	The figure reconciled against the general ledger
Network fee	The cost of processing the transaction, on a separate line	Recorded as a separate expense, never hidden in the net amount
Currency or asset	USDC, USDT, or fiat in USD, EUR or GBP	Determines the account and, where relevant, the day's exchange rate
On-chain identifier	The transaction's unique code on the blockchain	The verifiable reference for the entry, like a bank reference number

The report downloads as a CSV file, filterable by date range. For a calendar-month close, filtering from the first to the last day and exporting is enough. The resulting file is the base for reconciling against the general ledger, the same line-by-line procedure already covered in the reconciliation guide linked above.

The on-chain identifier: what replaces a bank reference number

The on-chain identifier, or hash, is a unique alphanumeric code that identifies a specific transaction on the blockchain, and it is the piece that replaces a bank reference number in a traditional wire transfer. No other movement, on any account, shares the same identifier.

The difference from a bank reference number is that the on-chain identifier is publicly verifiable. Anyone, including an external auditor, can take that code, look it up on the network's explorer, and confirm the amount, the date and the addresses involved, without depending on the company to hand over a copy of the record.

Does the on-chain identifier replace the invoice or the contract?

No. The on-chain identifier proves the money moved, not why it moved. The invoice, contract, or payment order explaining the business reason for the transaction is still required. The identifier and the commercial document together form the complete audit file; neither one replaces the other.

What document supports each type of transaction at close

Each type of transaction on Soulbit has a distinct supporting document, in addition to the on-chain identifier common to all of them. A collection is supported by the issued invoice; a supplier payment, by the payment order and the supplier's invoice; a payroll run, by the payroll calculation and the batch file.

Transaction type	Supporting document	Report field that references it
Collection from a client	Invoice or issued payment link	Gross amount and date on the report
Payment to a supplier	Payment order and supplier invoice	On-chain identifier and counterparty
Batch payroll disbursement	Payroll calculation and batch file	On-chain identifier per recipient
Conversion to fiat	Applied quote and conversion receipt	Exchange rate and local currency amount
Network fee	Transaction detail	Fee amount, recorded separately
Collection via QR or payment link	Receipt generated by Soulbit	On-chain identifier and gross amount

Batch payroll deserves a separate note. Each disbursement in a batch generates its own on-chain identifier, as explained in batch payroll disbursement, and that identifier is what connects the payroll calculation to the accounting entry for each recipient, across every country where the recipients are paid.

A payment collected through a QR code or a payment link works the same way as a direct collection for filing purposes. The receipt Soulbit generates at the moment of collection and the on-chain identifier of the transaction are the two pieces to file together, regardless of whether the client paid from a link shared by email or by scanning a code at a point of sale.

How to build the audit file for a single transaction at close

The audit file for a single transaction at month-end close brings together four pieces: the commercial document that originated the movement, the on-chain identifier of the transaction, the gross amount and the fee recorded separately, and the accounting entry that connects them. Without all four, the file is incomplete.

In practice, the process follows four steps. First, download the transaction report for the period. Second, filter it by transaction type: collections, supplier payments, payroll and conversions. Third, match each line of the report to its corresponding commercial document, using the on-chain identifier as the key. Fourth, file the filtered report, the commercial documents and a note explaining the policy applied, for example the source of the exchange rate used that month, together. The full anatomy of an on-chain transaction, for a team building this file for the first time, is covered in how an on-chain transaction works for an accountant.

What happens if a report line has no commercial document behind it?

That movement is flagged as pending until the team that originated it provides the invoice, contract, or payment order. An on-chain identifier without a commercial document does not close the file: it proves funds moved, not why they moved.

For a company with a monthly rhythm of 30 to 50 transactions, filing the commercial document the same day a transaction happens tends to work better than reconstructing a full month under a deadline. A file that is already assembled by the closing date is the one that raises the fewest questions when a reviewer, whether internal or an external auditor, examines it weeks or months later.

What Soulbit V1 delivers in reporting and traceability, and what it does not

Soulbit V1 delivers the complete transaction history, the on-chain identifier for every transaction, and a downloadable CSV report, filterable by date and by transaction type. It does not deliver an automatic integration with a company's accounting software or ERP: there is no API and no SDK connecting the two systems today.

The export is manual. The accounting team downloads the file from Soulbit and loads it into its own system, with the same approach it uses today for a bank statement or a payroll calculation. This is not a hidden limitation; it is the product's actual scope at this stage, and it is worth stating plainly, because a systems team expecting an automatic connector plans differently than one that knows, from the start, that the file is downloaded and loaded by hand.

Soulbit also does not generate Colombia's DIAN electronic payroll supporting document, a topic already covered in electronic payroll before Colombia's DIAN, does not calculate taxes, and does not classify the accounting treatment of a USDC balance. That IFRS classification, covered in the guide linked at the top, remains a judgment call for the accountant. Soulbit delivers the evidence; accounting, with its own judgments and rules, is built by the company.

For a controller consolidating entities in several countries, this scope matters more than it would for a single-country close. Each local entity still downloads its own transaction report and applies its own local retention rules, and the group's consolidation process still has to bring those separate reports together at the parent level. No part of that consolidation happens automatically inside Soulbit.

The report's scope is worth being precise about. Today it covers the stablecoin and fiat transactions that pass through Soulbit: collections, payments, payroll, conversions and network fees. It does not include a company's other accounts, such as a local bank account the same SMB may keep operating in parallel, and it does not consolidate that information. A company's full close still requires the accountant to bring this piece together with every other source in its books, the same way it handles any other bank statement today.

What an auditor expects for documentary support of a transaction

An auditor expects three things regarding the documentary support of a transaction: sufficient appropriate evidence that it occurred, a document explaining its business purpose, and a retention period consistent with each country's rules. The international auditing standard ISA 230 sets the minimum retention period for audit working papers ordinarily no shorter than five years from the date of the auditor's report, according to the IAASB handbook.

A company auditing operations in more than one country has to reconcile several local clocks with that single auditor clock. In Colombia, Article 28 of Law 962 of 2005 sets a ten-year retention period for commercial books and papers, counted from the last entry, document or receipt. In Mexico, Article 30 of the Federal Fiscal Code sets a five-year period, counted from the filing of the related tax return. Colombia's UGPP, on the payroll side, can audit up to five years back.

None of these clocks replace the others, and the longest one should govern the company's filing policy. A group closing its books across Colombia, Mexico and a third jurisdiction should keep the transaction report, the commercial documents and the exchange rate evidence for whichever local retention period is longest, plus the five-year window its external auditor applies under ISA 230. That combined policy, written down once, is simpler to apply consistently than deciding it transaction by transaction.