Changelog
Every shipped improvement to the MatchRail matcher.
rails
The receipt your ledger does not have
QuickBooks Online's Accounting API carries no goods-receipt entity of any name — item receipts are a QuickBooks Desktop feature — and Xero's /Receipts endpoint is, in its own specification's words, draft expense claim receipts. Checked against both vendors' own specifications rather than assumed.
So MatchRail owns that document: what arrived is recorded here, against the purchase order, and the matcher cannot tell it apart from one a rail supplied.
corrections
Corrections wait behind a kill window
Approving a correction queues it with an expiry rather than posting it. The dispatcher will not pick a row up before that expiry, and undo is a single conditional update that races the dispatcher's claim with exactly one winner.
Every scheduled, posted, killed and held correction writes an append-only audit row carrying the figures it acted on and the ledger's own reply.
queue
Only exceptions reach the queue
A match is clean if and only if it carries no variances, and the queue renders exceptions and nothing else. That biconditional is a test rather than a comment — if a clean match ever reached the queue, the matcher would be wrong.
Each exception shows the order, the receipt and the bill side by side, with the disputed line marked in all three columns.
matcher
Three-way match, nightly
The pass pulls what changed on each connected rail since its last watermark and matches every bill against its purchase order and its receipt — quantity, unit price and document total, all in integer cents so a floating-point rounding error can never invent or hide a variance.
A rail that does not answer does not advance the watermark, so an outage re-reads its window tomorrow instead of clearing a book on the strength of an empty answer.