By Lars Holdgaard, Founder of Debitura
Crypto can move across borders in minutes. The invoice behind that payment can still remain unresolved for months.
That contradiction matters to Web3 founders, consultants, and project managers. A customer may point to a transaction hash and say the bill was paid. The supplier may see the wrong token, amount, or address. Both sides can have a real blockchain record while disagreeing about the debt.
The practical answer is to maintain two connected records. The first records the commercial obligation. The second records the attempted settlement. Reconcile them before deciding whether the problem is a late payment, a short payment, a billing dispute, or a security incident.
Record one: what the customer agreed to pay
Start with the commercial record. It should identify the legal customer, the work or product supplied, the agreed price, the invoice currency, the due date, and the conditions for acceptance.
For a consulting project, that might include a signed statement of work, the billed milestone, the customer’s approval, and the final invoice. A purchase order can also show who had authority to commit the company.
If a US-dollar invoice may be settled in a digital asset, specify how the token amount will be calculated. State the pricing source, quote window, permitted network, fee allocation, and treatment of a transfer that arrives after the quote expires.
Without that rule, a visible transfer does not answer the central question: did the customer discharge the amount that was actually due?
Record two: what moved on-chain
The settlement record should capture the network, token contract, sending and receiving addresses, transaction hash, timestamp, token amount, and relevant fees. Keep the original payment instructions and the message in which the customer confirmed the transfer.
Ethereum documentation shows why this record is useful and limited. A transaction contains sender, recipient, signature, value, and fee information. It can show that a valid digital signature authorised a processed transfer from one address to another. It does not identify the legal company controlling either address or connect the transfer to a specific invoice.
Australia’s tax authority offers a useful example. Its crypto guidance asks for the date, purpose, other party or address, Australian-dollar value, exchange records, and wallet records. The lesson extends beyond tax: the transfer is only part of the business record.
Reconcile the two records before chasing payment
Put the commercial and settlement records side by side. Then classify the gap.
- No transfer exists: Confirm that the correct legal entity received a valid invoice and reminder.
- The transfer is smaller than the invoice balance: Check the conversion rule, quote time, token decimals, and fees before calling it a short payment.
- The customer used the wrong token or network: Check whether the receiving address can access the asset before promising recovery.
- The transfer went to an unapproved address: Treat it first as a possible security incident, not as an ordinary receivables dispute.
- The customer says the transfer settled another invoice: Ask for the remittance reference and compare it with the open account statement.
This classification prevents a common mistake: sending a generic late-payment demand when the real problem is valuation, attribution, or fraud.
Verify changed wallet instructions outside the email thread
Wallet instructions need the same change controls as bank details. A familiar sender name or an old email chain is not enough.
Scamwatch warns that fake invoice details can appear inside a genuine conversation after an email account is compromised. It advises checking details through independently sourced contact information.
When a wallet address changes, verify it through a second channel already on file and record who approved the change. For larger payments, a small test transfer can confirm that the selected network and address can receive funds, but it cannot prove who controls that address. Authenticate any changed instruction through an independently sourced channel before sending either the test or final amount, and use an allowlisted-address process where available.
Build the recovery file while the facts are fresh
If the due date passes, preserve a compact file before correspondence spreads across wallets, block explorers, chat apps, and inboxes. Include:
- the contract, order, or statement of work;
- the correct invoice and payment terms;
- proof of delivery or milestone acceptance;
- the customer’s legal name, address, and decision-maker;
- reminders, dispute messages, and proposed payment dates;
- approved wallet instructions and any change approvals;
- the transaction hash and a saved transaction record; and
- a one-page account statement showing the amount invoiced, value received, credits applied, and balance still due.
Australian government guidance follows the same logic: keep the contract, invoice, reminders, and relevant correspondence. The escalation route depends on the contract and customer’s jurisdiction, but a complete file makes it easier to assess.
Start with a calm reminder stating the balance, due date, and payment reference. Ask for a specific explanation and evidence if the amount is disputed. For an Australian creditor, international debt collection in Australia is one possible next step once the file is complete.
Faster settlement still needs better evidence
Blockchain infrastructure can reduce the time it takes to move value. It cannot decide which legal entity owes the money, whether a milestone was accepted, which conversion rule applies, or whether an invoice was fully satisfied.
The two-record method keeps those questions separate but connected. One explains the obligation. The other explains the transfer. Together, they help Web3 teams resolve routine mismatches and prepare a cleaner file when the problem becomes serious.
Author bio
Lars Holdgaard is the founder of Debitura and has 10+ years of experience across debt collection, accounts receivable, technology, and startups. Before Debitura, he co-founded and led product and technology work at startups and scaleups.
This is a sponsored article. Opinions expressed are solely those of the sponsor, and readers should conduct their own due diligence before taking any action based on information presented in this article.






Be the first to comment