The $140 Disagreement Inside One Invoice

Part 5 of 16 · Behind the Buy Button

The invoice says $1,260

Maya has invoiced the first shipment as 60 books at $21 each. eComm Inc's agreed price is $20. Its receiving team counted 58 books and accepted 56 under our assumed inspection rule.

The arithmetic on Maya's invoice is correct: 60 × $21 = $1,260. The commercial question is whether that is the right claim for this transaction. Correct multiplication cannot answer it.

The matching cheat sheet

Comparison	Question it adds	Our simplified result
Order and invoice	Do the claimed quantity and price fit authorized terms?	The invoiced price is $1 too high
Add receipt evidence	Does the claim fit what was counted?	Two invoiced books were not counted
Add acceptance evidence	Does it fit the accepted quantity?	Two counted books remain on hold

These are commonly called two-, three- and four-way matching controls. Oracle's Payables guide describes those additional comparisons and configurable tolerances. This is an external example of control mechanics, not evidence that Amazon applies a particular matching level or tolerance to every invoice.

Explain the $140 before deciding what to do

Under a deliberately strict rule for this example, the currently accepted base is:

Accepted base = 56 books × $20 = $1,120.

The difference from the invoice is $1,260 − $1,120 = $140. We can explain every dollar:

Component	Calculation	Amount
Price difference on the claimed shipment	60 × ($21 − $20)	$60
Two books not counted	(60 − 58) × $20	$40
Two books awaiting acceptance	(58 − 56) × $20	$40
Total difference	$60 + $40 + $40	$140

This decomposition first reprices all 60 claimed books at the agreed price, then separates the missing and held quantities. It does not count the same difference twice.

The $1,120 is an undisputed base under our teaching assumptions. It is not a legal determination of what eComm Inc owes, nor a recommendation to withhold the remaining amount. The contract could allocate transit loss or inspection risk differently. Matching identifies questions; applicable terms and authorized decisions resolve them.

A supplier-submitted invoice is not universal either. In an agreed evaluated receipt settlement process, the buyer can generate the settlement invoice from purchasing and receipt information. SAP describes this external example. We have not established Amazon adoption. The general requirement is an identifiable, authorized settlement basis, not one mandatory document sender.

What belongs in the accounts can be a different number

Assume separately that eComm Inc obtained control of all 58 received books, including the two held for inspection, and initially values them at $20 each. Its simplified receipt accounting would recognize a $1,160 inventory asset and a $1,160 accrued liability, subject to later quality or return adjustments.

Now we have three useful amounts: $1,260 claimed, $1,160 recognized under the assumption, and $1,120 currently accepted for the payment review. They differ for stated reasons. A disputed invoice does not automatically mean there is no obligation to record. Oracle's receipt-accounting overview illustrates the separation between receipts, accruals and later invoice matching; it does not establish eComm Inc's or Amazon's policy.

Resolve the questions one at a time

Maya agrees to the $20 price and issues a $60 credit. The corrected claim is $1,200. The two held books pass inspection, increasing the accepted base to $1,160. The missing two books remain unresolved.

Suppose the parties then agree that Maya will credit the $40 shortage. The final claim for this shipment is $1,160. A confirmed $1,160 payment allocated to that claim settles it under the example. The original $1,260 invoice and both credits remain in the history.

Forty books are still outstanding on the original order. Settling the first shipment must not close them accidentally. Nor does it explain away the operational question of how the shortage arose.

Reconciliation is allocation, not just comparison

One order can have several receipts and invoices. One bank transfer can settle several invoices. A control must prevent the same receipt quantity or payment amount from being used twice.

Maya needs a remittance explanation that identifies which invoices and credits the cash settled. eComm Inc needs owners and next actions for the residuals. A customer like me needs a similarly specific explanation when a partial refund arrives: which item or charge did it resolve?

The lesson I would take into a dispute is to replace “your total is wrong” with a table that both parties can investigate. The purpose of matching is an explainable result, including an honest account of what remains open.

Continue the series

Previous: Sent, Received, Accepted: Three Different Claims. Next: The Price After the Price. Return to the introduction and cheat sheet.

Evidence and method: public references were checked on October 18, 2026. The fictional scenarios, proposed controls and design conclusions are learning models, not claims about a real employer. Reported financial figures retain their stated measurement dates.