Three-way match when the payment settles on-chain

Three-way match is unchanged by the settlement rail. Purchase order, goods receipt and supplier invoice still have to agree on what was ordered, what arrived and what is being billed, and none of that touches how the money moves.

What changes is what happens after the match passes. In a wire process, payment execution produces a bank reference that your bank will stand behind. On-chain it produces a transaction hash, which is stronger evidence in some respects and much weaker in others. Teams that treat the hash as a drop-in replacement for a bank reference end up with an audit file that does not hold together.

This article covers what the hash actually proves, what it does not, and what belongs in the payment file alongside it.

What the three-way match still does

The purpose has not moved: confirm the company owes the amount before it leaves.

• Purchase order establishes what was authorised and at what price
• Goods receipt establishes what was actually delivered
• Invoice establishes what the supplier is claiming

Discrepancies between any two are resolved before payment. That logic is rail-agnostic and should not be weakened because the payment is novel. If anything it deserves more weight, because the payment step that follows is irreversible.

The practical risk when a company starts settling in stablecoins is that payments begin flowing through a parallel path, outside the ERP, operated by whoever set up the wallet. The match gets skipped not by decision but because the new rail bypassed the system the controls lived in. Worth checking directly: can someone pay a supplier in USDC without an approved PO, and would anyone notice?

What a transaction hash proves

More than a bank reference, in a narrow sense. A confirmed transaction hash is cryptographic evidence that:

• A specific amount of a specific token
• moved from one address to another
• at a specific block height, which is a definite point in an immutable sequence
• and the transfer is final

Anyone can verify this independently without asking you or your bank for anything. No confirmation letter, no intermediary attestation. For existence and amount, this is better evidence than a bank statement line.

What it does not prove

Three things, and each one is a gap the audit file has to close.

Who controls either address. The chain shows a transfer between two strings. It does not know that the sending address is your company's treasury or that the receiving address belongs to your supplier. That link lives entirely in your records. Without it, a hash proves that money moved somewhere, which is not the same as proving you paid your supplier. This is why address ownership documentation matters, covered in how to prove a wallet belongs to your company.

What the payment was for. A transfer carries no invoice number unless someone attached one, and most exchange-originated payments cannot carry one at all. The hash is not self-describing.

That it was authorised. The chain enforces the signature rules on the account, which is real evidence about who signed. It says nothing about whether an approval policy was followed, whether the invoice was matched, or whether the amount was right.

The fourth document: the payment file

In practice the on-chain equivalent of a complete payment record needs five things, and the hash is only one:

1. Transaction hash and block height, as the settlement evidence
2. Sending address, mapped to a documented company account
3. Receiving address, mapped to the vendor record and its verification evidence
4. Invoice reference, from your system since the chain will not carry it
5. Approval record, showing who authorised and under which threshold

Items 2, 3 and 5 are the ones most often missing, and they are the ones an auditor will ask for. The hash alone is the part everyone remembers to keep.

Where the signature threshold fits

A useful property of smart-account settlement is that authorisation evidence is partly on-chain.

With a multisig account, the transaction itself records which keys signed and the threshold that was required. That is verifiable evidence of who approved a payment, independent of your internal systems, and it cannot be edited after the fact. A bank payment file can be altered; a confirmed signature set cannot.

The limitation is that it tells you which keys signed, not which people. The link from key to person is your record to maintain, which means a current roster mapping signer addresses to named individuals and roles is part of the control, not an administrative afterthought.

It is also worth keeping the approval matrix and the on-chain threshold aligned. If policy says payments over $50,000 need the CFO but the contract threshold is any two of five signers, the contract governs and your policy is decorative. Plaitr enforces the threshold in the Squads smart account itself, so what the policy says and what the chain allows are the same thing. See security and control.

Settlement timing changes the exception workflow

One practical consequence worth planning for: on-chain settlement is effectively immediate, so the gap between approval and irreversibility collapses.

In a wire process there is often a window where a payment is submitted but recoverable, and teams rely on it more than they admit. That window is where a lot of errors are caught. On-chain it does not exist.

The compensating control is to move the exception check before release rather than after. Anything your team currently catches in the post-submission window needs to move into the approval step, because there will be no post-submission window. Duplicate prevention in particular has to be preventive, which is covered in preventing duplicate payments when there is no reversal.

FAQ

Does three-way match still apply to crypto payments?

Yes, unchanged. Purchase order, goods receipt and invoice are matched before payment exactly as they would be for a wire. The settlement rail does not affect whether the company owes the money. The risk is that on-chain payments route around the system the match lives in, so confirm that paying in stablecoins requires the same approvals as paying by wire.

Is a transaction hash sufficient evidence of payment?

It proves an amount moved between two addresses at a block height, and anyone can verify that independently. It does not prove who controls the addresses, what the payment was for, or that it was authorised. A complete payment record needs the hash plus address ownership mapping, the invoice reference and the approval record.

How do auditors verify an on-chain payment?

Typically by confirming the transaction on a block explorer at the stated block height, then tracing the addresses to your documented ownership records and the payment to its invoice and approval. The on-chain part is the easy half; the questions concentrate on address ownership and authorisation.

Does a multisig signature prove who approved a payment?

It proves which keys signed and that the required threshold was met, which is tamper-evident and cannot be altered afterwards. It does not prove which people hold those keys. Maintain a current mapping of signer addresses to named individuals and roles, and treat changes to that roster as a controlled event.

What replaces the recall window for catching errors?

Nothing does, which is why checks move earlier. Any control your team currently applies between submission and settlement has to move into the approval step, because on-chain settlement is final on confirmation.

What should you do next?

Audit one payment end to end. Take a recent on-chain payment and try to assemble all five elements of the payment file from your systems. Whichever one you cannot produce is the gap to close before your next audit.

Plaitr keeps approvals, the payout rail and the ledger entry in one place, so the payment record arrives complete rather than being assembled afterwards. See auto accounting and business banking.