It reconciles the purchase order, the receipt and the bill against each other overnight, and hands you only the ones that disagree. A bill that matches its order and its receipt inside tolerance is cleared and you never see it. The queue is the exceptions, and nothing else.

A variance clears only when it is inside BOTH bands: 1% of the figure on the purchase order AND $25 in cash. The tighter one always binds, so a small bill is governed by the percentage and a large one by the dollar ceiling. Quantity has no tolerance at all — a unit is on the dock or it is not.

No. A correction is queued when you approve it, not posted. It waits 60 seconds behind a kill window, writes its own audit row, and the dispatcher re-checks the figure against the current documents before it writes anything. Anything outside tolerance is never auto-posted at all.

Three columns: the purchase order, the receipt and the bill, side by side, with the disputed line marked in all three and the reason written out in words — “billed 24, received 21”, “ordered at $12.50, billed at $14.10”. You are reading the disagreement, not taking our word for it.

No, and it never asks to be. MatchRail has no bills of its own, no payment run and no chart of accounts. It reads the documents in the ledger you already close on and hands back a short list. If you switch it off tomorrow, your books are exactly where you left them.

A bookkeeper closing the month on QuickBooks or Xero, for a business that raises purchase orders and takes deliveries — anyone whose close currently involves opening three documents per bill and checking they agree, or quietly sampling because there is not time to check them all.

Four things, all in code. The tolerance decides whether one match is the agent's to clear. The auto-clear cap stops it clearing more than 500 in a day — past that, everything queues for you regardless. The post cap stops it writing more than 50 corrections into your ledger in a day. And the dispatcher refuses to post a figure that has moved since you approved it.

No, and that is deliberate. There is no --force, no allowlist and no known-issues file anywhere in MatchRail. A gate that can be waived is a gate that gets waived, usually at the worst possible moment, and every one of these gates fails toward showing you more rather than less.

No. The matcher is arithmetic — quantities compared, unit prices compared against the order, totals compared against price times quantity received, all in integer cents so a floating-point rounding error can never invent or hide a variance. A model that is right 99% of the time is the wrong tool for a control an auditor will ask about.

Only ones it can derive from the three documents in front of it: re-price a line to the order's price, re-quantity a line to what arrived, void a second copy of a bill. Where two disagreements overlap it proposes nothing and says so, because a guess written into a ledger is worse than no guess.

Close it. The exception becomes “closed” rather than “clean” — its variances stay attached to it forever, and the audit trail records who overruled the matcher and when. Marking it clean would destroy the evidence of what was overruled, which is exactly what an auditor is looking for.

Yes, for at least 60 seconds. Approving queues the correction with an expiry stamped on it; the dispatcher will not pick it up before that expiry, and undo is a single conditional database update that races the dispatcher's claim with exactly one winner. If undo wins, nothing was ever written.

Purchase orders and bills come out of QuickBooks or Xero. Payments come from Stripe, so a bill that was paid before its match passed is flagged. The receipt is recorded in MatchRail — because neither QuickBooks Online nor Xero has a goods-receipt document at all.

Because they do not have them. QuickBooks Online's Accounting API carries no item-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, meaning employee expenses. Xero purchase orders go from authorised straight to billed with no received state. That gap is exactly why a bookkeeper on either ledger cannot do a three-way match today.

The narrowest grant that does the job. Xero is connected read-only; Stripe is connected read-only. Only QuickBooks is asked for write access, and only so an approved correction can be posted back. Tokens are encrypted at rest in a table with row-level security on and no policies, so nothing but the server ever reads them.

The match runs nightly against what changed on each rail since its last watermark, so it reads a night's worth of documents rather than your whole ledger. You can also pull and re-match on demand from the Rails page when you want an answer before tomorrow morning.

The pass records the failure and does NOT advance its watermark, so tomorrow re-reads that window instead of skipping it forever. An empty answer from a ledger is indistinguishable from “nothing was billed”, and a matcher that accepted one would quietly clear a book on the strength of an outage.

The stored token is deleted, not flagged. A row marked disconnected that still holds a live refresh token is a standing write grant on your general ledger sitting in a database, and “we stopped using it” is not the same as “we no longer have it”. The documents already pulled stay in your account until you delete them.