Crypto Underpayments and Overpayments: A Reconciliation Sheet

Compare like amounts

Use the invoice's network, asset, precision, exchange-rate terms and validity period. Compare the amount actually delivered to the correct destination with the amount requested in that same asset. The sender's total wallet debit may include a separate network fee, so it is not automatically the received amount.

Keep any fiat invoice value and conversion quote as separate fields. If the quoted asset amount changes after expiry, do not silently use today's price to rewrite yesterday's obligation. Record the contractual rate, expiry and policy for late payment. A tolerance, if permitted, should specify units, bounds and approval ownership.

Respect the provider's exception behavior

BitPay's invoice documentation distinguishes base states from exception states such as paidPartial and paidOver, and describes provider-managed refund treatment. That behavior is a concrete provider example, not permission to offer the same top-up, credit or refund choices in another system.

Check whether the provider has already initiated a return before an operator acts. A manual return on top of an automatic return can create a second loss. Bitcoin's payment-processing guidance also explains why refunds need their own transaction flow; the original transfer does not safely identify every required return detail. Follow the provider and custody process rather than inventing a return address from a support message.

Keep the resolution as a linked decision

The exception record should state the verified amount, difference, reason, permitted options, decision owner and final transaction references. A small shortfall may be accepted only where the approved terms allow it. A top-up needs a way to link both transfers without creating duplicate invoices. A refund must be checked against already credited value and existing return instructions.

Wrong-network or unsupported-asset cases require a different escalation path from ordinary arithmetic differences. Do not promise recoverability or a completion time merely because a hash exists. Preserve the evidence and communicate the actual state: received and unmatched, provider return pending, credited under an approved exception, or unresolved.

Worked example: a fictional asset invoice

An invoice requests 250.00 units of fictional token T on network N. The verified destination receives 248.50 T, leaving a 1.50 T shortfall. The sender's wallet shows a 0.30 N-native-asset network fee; that is a separate asset and cannot explain the shortfall by subtraction. In an alternative case, receipt of 253.00 T creates a 3.00 T excess. These cases require the actual provider's resolution policy, not an automatic extra client credit.