All articles
6 min read

From Invoice Auditing to Transaction Verification

Invoice auditing is a document-comparison discipline. Transaction verification is an evidence discipline — and it generalises far beyond freight.

Invoice auditing and transaction verification are often described as the same activity. They are not. The difference is the object of study. Auditing studies documents; verification studies obligations and the events that satisfy or fail them.

Two different questions

  • Auditing asks: is this invoice internally consistent with the rate table and the contract terms?
  • Verification asks: did the conditions that create this obligation actually occur, according to sources the biller does not control?

Both questions are worth asking. Only the second one produces an artifact you can take into a dispute, because only the second one is grounded in something outside the billing party's own account.

Why the pattern generalises

Freight detention is a convenient starting point because the obligation is narrow, the arithmetic is unambiguous and independent evidence is unusually available. But the shape of the problem is not specific to freight. Every contract-based transaction has the same structure: a contract creates obligations, obligations have conditions, conditions are satisfied or not by real events, and events can be evidenced.

  • Procurement — did the delivered quantity and specification match the purchase order terms?
  • Construction — was the milestone that triggers a progress payment actually reached?
  • Insurance — do the recorded conditions satisfy the policy's coverage trigger?
  • Manufacturing — was the contractual tolerance or throughput commitment met?
  • Logistics beyond detention — demurrage, storage, layover, redelivery and equipment use.

What has to be built once

If the architecture is right, the domain-specific part is small. The reusable core is an obligation model with structured conditions, an extensible evidence layer with per-source provenance and reliability, an event reconstruction step that surfaces conflict, a deterministic calculation layer, and an immutable, versioned record of results. Adding a new obligation type means adding a condition template and a calculation — not rebuilding the platform.

That is the reason to describe this work as an evidence layer for commercial obligations rather than as invoice auditing. The document-comparison framing caps the ambition at catching billing errors. The obligation framing points at something larger: knowing, before money moves, whether what was billed is what happened.