Commodity Trade Invoicing: Why the Invoice Is Where a Trade First Has to Agree With Itself

Summary

A commodity invoice looks like a record of something that has already happened. It is not. It is an assertion, made outward, to a party whose interest lies in checking it — and it is the first moment in the life of a trade at which every provisional number has to stop being provisional at once, on one day, inside one document.

This article sets out what a commodity trade invoice is actually assembled from, why so much of it is still unsettled at the moment it has to be issued, why invoicing is where upstream defects surface rather than where they are created, and what has to be recorded about an invoice before the question "how much are we owed on this cargo" has a single answer. It is written for the people who raise, check, dispute and chase these documents — settlement and finance, the operations desk whose measurements and claims end up inside them, and the middle office that has to explain the difference.

If you want the mechanism, start with An invoice is an assertion, not a record. If you already accept that and want to know why one cargo keeps producing more than one invoice, start with The parts of an invoice do not become final together.

An invoice is an assertion, not a record

Every other number a trading company produces is checked by people who work there. An invoice is the first one checked by somebody who is paying for it.

This is the property that makes invoicing different from everything upstream of it. A position report can carry a stale differential for a week and nobody outside the company will ever know. A trade capture record can name the wrong incoterm and it will sit there until someone happens to look. An invoice with the wrong quantity on it goes to a counterparty whose settlement team is paid to find exactly that, who has their own copy of the contract and their own record of what arrived, and who has no reason at all to let it pass.

The consequence is worth stating plainly, because it changes who owns the problem. Invoicing is where upstream defects are discovered, not where they are made. A settlement desk that raises a high proportion of invoices that come back queried is not necessarily a settlement desk doing poor work. It may be a settlement desk operating downstream of a contract file, a measurement chain and a claims process that never had to be right in public before. The rate of queried invoices is a reading on the whole lifecycle; it is taken at the last station, and it is habitually attributed to the last station.

That misattribution is expensive in a specific way: it directs the fix at the point of discovery. Checking harder at the invoicing step catches more errors and catches them later. It does nothing about where they came from.

The parts of an invoice do not become final together

An invoice is a single number computed from inputs that mature on different schedules, none of which is the invoicing schedule.

Consider what has to be settled before one line can be stated. There is a quantity, which came from a measurement taken at a jetty or a meter, possibly disputed, possibly subject to a survey the two parties commissioned jointly and possibly not. There is a price, which for a physical commodity is frequently not a number agreed at trade time but a formula that resolves over a pricing period — a period that can end well after the goods have moved. There is a quality adjustment, which depends on a laboratory result. There is freight, which depends on a voyage. There are claims — demurrage above all — which are not a calculation but a negotiation, and which are agreed when the parties agree, on no schedule anyone controls. And there are duties and taxes, which depend on facts about the movement that may themselves be settled late.

None of these is unusual. What is unusual is that the invoice is the one artefact that requires all of them simultaneously. Everything before it is allowed to hold a provisional value: the risk system can carry an estimated differential, the operations file can carry a laytime accrual, the contract file can carry "TBC" against a discharge port. The invoice is the point at which every "to be confirmed" in a trade has to be confirmed or explicitly deferred, and there is no third option.

This is why provisional invoicing exists at all. It is not an administrative convention and it is not sloppiness. It is the direct structural consequence of a document that has to be issued before its own inputs have resolved, because waiting for them would mean not being paid for months. A provisional invoice is what a company issues when it needs cash on a schedule that the trade's own facts will not meet.

Provisional and final are two different claims, not two versions of a file

A final invoice is not a corrected copy of the provisional one. It is a second assertion, about the same cargo, that has to be reconciled against the first, and the relationship between them is a fact somebody has to hold.

In most operations that relationship is held by a person. The provisional invoice was issued in one month against an estimated quantity and a price that had not finished forming; the final invoice arrives later, against measured quantity and a resolved price; somewhere between them a credit note may have moved a quality adjustment. Each of these is a document. Each was emailed. Each has a number in an accounting system. What no system necessarily holds is the statement these three documents are one claim — and once that statement lives only in a spreadsheet column or in the memory of the person who raised them, the exposure on that cargo is only correct while that person is available.

The practical test is simple and uncomfortable. Take a cargo that has been provisionally invoiced, finally invoiced and credit-noted. Ask what is currently owed on it, and ask how the answer was obtained. If the answer required somebody to open a mailbox, the invoice chain is not recorded anywhere; it is being reconstructed on demand, and every reconstruction is a fresh opportunity to reconstruct it differently.

The counterparty is running the same calculation from different copies

An invoice dispute is almost never a disagreement about arithmetic. It is a disagreement about which inputs are the true ones, held between two parties who both did the sum correctly.

The buyer computes the same invoice you did. They use their contract copy, their record of the pricing period, their surveyor's figure or their reading of the joint one, their view of which hours counted as laytime. When the two results differ, both sides are looking at a correct calculation performed on different premises. Nobody has made a mistake in the ordinary sense, which is exactly why these disputes resist being resolved by recalculating: recalculating reproduces the disagreement.

What resolves them is producing the underlying document — the survey report, the notice of readiness, the pricing publication for the relevant dates, the amendment that changed the discharge window. The time to settle an invoice dispute is therefore set by how quickly the supporting documents can be found, not by how quickly the numbers can be recomputed. In an operation where those documents live in mailboxes and shared drives organised by whoever filed them, that is the whole of the delay.

There is a second-order effect worth noticing. Because the resolution mechanism is documentary, a counterparty who is slow at producing documents has, in effect, a free option to delay payment while remaining entirely within the terms of the contract. Nothing about that is bad faith. It is a structural feature of settling by correspondence.

Correcting an invoice is expensive because the correction is public

Upstream, a wrong number is edited. From the invoice onward, a wrong number has to be withdrawn by issuing another document that says so.

This asymmetry is the reason the cost of a data defect steps up sharply at exactly this point in the lifecycle. Before issuance, an incorrect quantity is a field somebody changes. After issuance, the same correction requires a credit note or a re-issued invoice; it may require the counterparty's accounts payable process to be restarted; it may disturb a document set that a payment obligation depends on; it will certainly be visible to the other side, and it will be remembered by them the next time they decide how carefully to check.

The important consequence is not reputational, it is operational: the value of finding an error is highest immediately before the invoice is raised, and it falls off a cliff immediately after. Most invoice checking effort is applied on the wrong side of that line — after issuance, in the form of query handling. The same effort spent assembling the invoice's inputs before it goes out is worth considerably more, and it is harder to schedule because at that moment nothing is visibly wrong yet.

Invoicing needs less specialist judgement than almost anything around it, and that is what makes it a data problem

Most of what makes back-office work hard is scarce judgement. Invoicing is the exception: the work is heavy, repetitive and expensive to get wrong, but the rules for doing it are written down in the contract.

This distinguishes it from most of its neighbours in the trade lifecycle. Valuing a structured hedge, deciding whether a counterparty is good for the credit, arguing a demurrage claim, deciding what a regulatory submission has to contain — these are hard because they require someone experienced to make a call. Raising an invoice for a cargo is not hard in that sense. Given the contract, the measured quantity, the resolved price, the applicable adjustments and the claims position, the invoice follows.

The whole difficulty is in the word given. The bottleneck in invoicing is not expertise; it is fact availability. That single distinction determines what actually helps. A step limited by scarce judgement improves by hiring or training. A step limited by fact availability does not improve when you add people to it — it improves when the facts arrive earlier, in a form the step can consume, from wherever they are currently sitting. Adding checkers to a fact-availability problem produces more thorough re-derivation of information that was already known somewhere else in the company.

This is also why invoicing tends to look, on any process map, like a step that ought to be straightforward and, in practice, absorbs a great deal of a settlement team's month.

What each part of an invoice is waiting on

Two things are visible in this table that are not visible in any single invoice. The first is that the column that decides the timetable is the second one, and none of its entries is the settlement team. The second is that the failure modes in the last column are not variations on one problem — a quantity that is wrong is a different kind of event from a demurrage claim that has not been agreed yet, and an invoicing process that treats both as "pending" has flattened away the distinction that tells you which of them will still be open next quarter.

The same cargo, three documents, one claim

The bottom row is the one to sit with. Each of these three documents is individually well formed and individually correct. The defect does not live in any of them; it lives in the relationship between them, which is the one thing that is not a document and therefore the one thing that is easy not to store.

Three questions your own invoice file should be able to answer

These are not audit questions. They are questions about where the facts are.

One: for a cargo invoiced provisionally, what specifically is still outstanding, and who owns it? Not "the final invoice is pending" — which input, and whose desk. If the answer requires an email search, then what is outstanding is not being tracked; it is being remembered.

Two: when an invoice comes back queried, what is the average distance between the query and the document that settles it? Measured in steps, not in days: is the supporting document in a system, in a folder, in somebody's sent items, or with a third party who has to be asked for it. That distance is your dispute cycle, and it has almost nothing to do with the size of the dispute.

Three: can you list the cargoes on which you have issued something and not yet been paid, without building the list? If producing that list means asking three people and merging what they send back, then the list does not exist between the times you build it — and every version of it is a fresh reconstruction with its own errors.

Questions people ask about this

Why do we invoice provisionally at all — can't we just wait for the final numbers?

You can, and some contracts are structured that way, but the wait is usually longer than the business can fund. Quantity, price, quality and claims resolve on schedules set by surveyors, publications, laboratories and negotiations, and the last of them can be a long way past delivery. Provisional invoicing exists because the alternative is extending credit to a counterparty for the whole period during which your own inputs are maturing. The choice is not between provisional and correct; it is between provisional and unpaid.

Whose fault is it when a high proportion of our invoices are queried?

Usually not the team raising them, though that is where the number is measured. An invoice is computed from a contract, a measurement, a price resolution and a claims position, and a defect in any of those becomes visible for the first time when the counterparty checks the invoice. Before treating it as a settlement performance problem, it is worth categorising a few months of queries by which input was wrong. If they cluster on one input, the problem has a location, and it is upstream.

Should the invoice be raised from the trading system or from the accounting system?

The system that raises it matters much less than where its inputs come from. An invoice raised from a trading system that does not hold the survey figure, and an invoice raised from an accounting system that does not hold the pricing formula, fail in the same way: somebody assembles the missing part by hand and the assembly is not recorded. The useful question is not which system issues the document but whether every input on it can be traced to the place the fact first existed.

How do we stop demurrage from arriving as a surprise after the invoice has settled?

By treating the claim as something that exists from the moment the delay occurs rather than from the moment it is agreed. Demurrage is unusual among invoice components in that its timetable is a negotiation, so it will frequently not be ready when the commercial invoice is. That is manageable if the exposure is visible while it accrues and is deliberately excluded from the invoice; it is unmanageable if the first anyone hears of it is a claim document. The fix is upstream of invoicing entirely.

Is invoice reconciliation the same thing as settlement reconciliation?

They overlap and are worth separating. Invoice reconciliation asks whether what you asserted matches what the counterparty accepted. Settlement reconciliation asks whether the cash that arrived matches what was owed, which can go wrong for reasons that have nothing to do with the invoice — a payment netted across several cargoes, a deduction applied without notice, bank charges, a partial payment against a disputed line. Conflating them produces a reconciliation that cannot say whether the problem is with the claim or with the payment.

We invoice on the same terms every time. Why does this still take so long?

Because the terms are the part that is stable and the inputs are the part that is not. Repetition helps with the parts of the work that are the same each time — the format, the calculation, the approvals — and those are rarely where the month goes. The time goes into obtaining a figure that somebody else holds, chasing a result that has not been issued, and establishing which version of a document is the current one. Standardising the invoice does not standardise its inputs.

What is the first thing to fix if our invoicing runs on spreadsheets and email?

Not the spreadsheet. Start by recording, for each cargo, which invoice documents relate to it and what state that claim is in, so that the question "what are we owed on this cargo" has an answer that is stored rather than assembled. That single change removes the failure that survives every other improvement — the one where each document is correct and the total is wrong. The tool holding the result can stay exactly where it is while you do it, and doing it will show you whether the tool was ever the constraint.

Does this get better as we trade more?

Not on its own. Volume multiplies the number of cargoes in a provisional state at any moment, and it lengthens the list of counterparties whose checking behaviour and document-production speed you have to accommodate. What genuinely changes with scale is that the cost of the manual assembly becomes visible enough to act on. The work of fixing it, though, is the same at any size: it is a change to where the facts are captured and how early, not a change to how many people check the output.

Where this lands in a trading system

Nothing above is an argument for buying software. It is an argument about which facts have to exist before a document is sent, and how early. But the conclusions do map onto system capabilities, and it is worth being specific about which ones — and about where the mapping stops.

The first conclusion is that an invoice draws on the contract, the physical movement, the pricing outcome and the settlement position at the same time, and that these have to be in one place before the document can be assembled rather than reconstructed. That is what a CTRM/ETRM system providing complete trading lifecycle management for commodity traders, integrating physical trade, financial hedging, risk control, and settlement in one platform is for; Time Dynamics' Fusion is one, and among its stated capabilities the relevant one here is automated financial settlement and payment processing.

The second conclusion is that several of an invoice's inputs are not in that system at the moment they are needed. Survey figures arrive as documents, quality results arrive from laboratories, claims accrue in an operations spreadsheet, and counterparty acknowledgements arrive in a mailbox or on somebody's portal. That is a different problem, and it is the one X-Ray addresses: a non-invasive data processing and analysis platform, whose collection toolkit XDK performs non-invasive automated data collection from databases, Excel files, and web interfaces, and which is designed to collect data without disrupting existing systems or workflows. The last property is the one that matters here, because the spreadsheet holding your accruals is working, and the plan cannot be to replace it before you can see it.

The third conclusion is that the outstanding-invoice picture has to be re-cut — by counterparty, by cargo, by state, by what each open item is waiting on — more often than it can be rebuilt by hand. X-Sheet does one-click generation of personalized reports with Excel-like interface.

And here is where it stops. None of this is an accounts receivable system, and none of it settles a dispute. It will not agree a demurrage claim, it will not decide whether your counterparty's surveyor or yours is right, it will not turn a provisional price into a final one before the pricing period ends, and it will not make a counterparty pay. It also does not decide what your contract says you may invoice for; that is a document two companies negotiated, and no platform has standing to reinterpret it. What a system can settle is narrower and duller than the problem described here: where each input is captured, how soon after it exists, and whether the person assembling the invoice can see it without asking someone. That is most of the gap between an invoicing process and an invoicing rebuild, but it is not the whole of it, and it is worth being clear about which part you are buying.

See the products → · Talk to us about trade lifecycle data →

A note on the evidence in this article

This article contains no statistics, and that is deliberate rather than an omission. The observations behind it — which steps in the trade lifecycle are still run on spreadsheets and email, which of them carry costs that land directly in cash, and how much of a settlement team's month goes into obtaining facts rather than applying judgement — come from material we are not in a position to publish as a citable figure. Quoting a number we cannot source would make the argument look stronger and would make it worth less.

So the argument here is structural instead: each claim is made from the mechanism, and each is stated in a form you can check against your own operation rather than take on our authority. The three questions above are the intended way to use it. If your own invoice file contradicts what is written here, your file is the better evidence.