A System That Can Remember Why

Part 14 of 16 · Behind the Buy Button

Could someone reconstruct the story next month?

Maya and eComm Inc have resolved the first book shipment. The original invoice was $1,260, two credits totaled $100, and the final payment was $1,160. If the system now stores only “paid: $1,160,” it has preserved the ending and discarded the explanation.

This essay proposes a way to organize the evidence. It is my design synthesis for learning, not Amazon's internal architecture or a claim that one software product implements it.

Seven questions, seven independent states

Dimension	Question	Example that can remain open
Authority and commitment	What was authorized and agreed?	Forty books still outstanding
Performance	What happened?	Two shipped books were not counted
Acceptance	What met the requirements?	A quality decision awaits evidence
Claim	What does the supplier demand?	A disputed invoice amount
Accounting	What was recognized?	An uninvoiced accrual
Settlement	What obligation was discharged?	Cash received but not allocated
Message processing	What happened to the transmission?	A retry needs investigation

A transition in one row should not silently certify another. Amazon's transaction-status documentation supplies a concrete reason to preserve the last distinction: it concerns submitted messages, with operation-specific semantics.

Keep the records and the relationships

A useful model identifies parties, agreements, commitment lines, performance events, acceptance decisions, claims, accounting events and settlement allocations. The relationships carry meaning: this invoice line claims payment for that shipment; this credit corrects that price; this payment settles those claims.

The same order may have multiple shipments. A single invoice may cover multiple lines. A single payment may settle multiple invoices. These are many-to-many relationships, which simply means the records need not pair up one for one.

For each link, retain the quantity or amount allocated, its unit or currency, effective time and supporting evidence. Otherwise, a correct-looking link can consume the same receipt twice.

A conservation check that earns its place

Suppose a receipt records 58 copies and none of that evidence has yet been matched to a claim. Matching 40 copies to one invoice leaves receipt evidence for 18 copies available for another, before later returns or corrections. This allocation consumes matching capacity in the record; it does not move books or reduce stock on the shelf.

Remaining receipt quantity = 58 − 40 = 18 copies.

Allocating another 25 would exceed that evidence by seven copies. The system should expose the difference, not silently invent a larger receipt. This is a proposed control for a simple same-unit case, not a universal payment rule.

Similarly, a $1,160 payment allocated as $700 and $460 has no residual. If allocations total $1,150, the remaining $10 needs an explanation. Fees, foreign exchange, withholding and rounding require explicit treatment where relevant. “Make it reconcile” is not a sufficient reason to erase a difference.

An identifier needs its surroundings

Invoice number 1001 may exist at several suppliers. A safe record needs the relevant supplier, buyer and source-system context. A new message containing the same invoice may be a retry, a correction or a duplicate claim; the message identifier alone cannot decide.

Keep original payloads and their interpreted fields linked. The software quantity example from Part 12 shows why: a transport field can encode money rather than licenses. Normalization should explain a source, not destroy the source needed to check the interpretation.

Keep both kinds of time

Suppose books were received on September 30 and entered into the system on October 2. The event date and the recorded date answer different questions. One concerns the economic period; the other reveals a reporting delay.

Retaining both lets us reconstruct the best current view and what decision makers knew on September 30. A later correction should explain its effect without pretending the corrected information was always available.

The same applies to policy versions. If a tolerance changes, an earlier decision should still show the rule that governed it. We can then distinguish a wrong rule from a rule applied incorrectly.

Reconciliation needs something independent to compare

Invoices and accounting entries can agree while both omit an entire month of maintenance. Completeness requires an appropriate independent population: service periods, received goods, metered usage or certified project work.

A receipt copied from an ASN is weak corroboration of that ASN. An acceptance note copied from an invoice is weak corroboration of the invoiced work. The origin of the evidence matters as much as the existence of a second record.

For Maya, a system that remembers can explain a dispute. For eComm Inc, it can assign responsibility and prevent repeated errors. For a customer, it can explain a partial refund. My test is whether another person could reconstruct the result without trusting the confidence of the person presenting it.

Continue the series

Previous: One Transaction, Several Accounting Clocks. Next: Safety Before Speed: What a Green Tick Cannot Approve. 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.