Inspiration
Small traders buy on handshakes. A logo designer quotes $200 in a chat, the buyer says yes, and days later an invoice for $260 arrives. Nothing evil needs to have happened — a typo, a shifted line, a forgotten discount — but the buyer pays against a document that was never checked against the agreement, because in informal trade there is no purchase order, no ERP, no three-way match. Frontier agent-payment systems bind payment at checkout and never see the invoice that arrives later. Accounting systems see the invoice but never held the money. We built the missing middle: hold the money first, then make the invoice answer to the agreement.
What it does
Reconciliation Guardian is a buyer-side agent for informal trade:
- Mandate. The buyer forwards the agreement — a pasted quote or chat message. A deterministic parser drafts a mandate card (payee, items, quantities, unit prices, currency, cap) and cross-checks its arithmetic: every number must be in the source text, and a stated total that disagrees with the line sum is flagged, never silently fixed. The buyer confirms the card; the mandate is then frozen and identified by a SHA-256 hash of its canonical form.
- Hold. The confirmed mandate opens a hold for exactly the capped amount (PayPal Orders v2, intent AUTHORIZE). This is a hold, not a payment — reversible, and nothing has been paid.
- Reconcile. When the seller's invoice arrives, deterministic code — no LLM anywhere near the money path — matches it line by line against the frozen mandate: payee, currency, items, quantities, unit prices, total, cap, plus duplicate-invoice detection and a payee-memory profile (what this supplier normally bills).
- Three verdicts, tiered autonomy. Exact match → the agent releases exactly the verified amount on its own. Small drift within ±5% → the money waits and the human decides. Anything harder — duplicate, payee shifted, over cap, changed lines → BLOCK: nothing moves.
- The repairable drift receipt. A BLOCK issues a drift receipt (agreed / billed / what changed — facts, no accusations) that carries a no-install repair link bound to that one invoice. The seller opens it on their phone, corrects the drifted line, and the corrected invoice re-enters the same gauntlet against the still-open hold. On match, the hold releases the verified amount and the remainder returns to the buyer. A joined receipt (mandate → invoice → release) is stored as the evidence chain.
How we built it
- Core (deterministic, zero dependencies): mandate freeze (canonical JSON + SHA-256), a line-by-line reconciler with the three-verdict rule, integer-cents money (no floats anywhere near money), payee memory, and receipt builders — all in plain Node.js modules with a test suite (19 tests, every verdict path asserting both the verdict and the money state).
- Settlement behind one door: two backends, one interface. The live backend moves money only through raw PayPal REST (Orders v2 authorize / capture with final_capture semantics / void); the mock backend is an in-memory ledger whose IDs are always MOCK-prefixed — mock money is never presented as PayPal money. The guardian core never knows which backend settled a hold; the demo server picks one with BACKEND=mock|live.
- Money discipline: the LLM never holds money tools; money tools are not even registered with it. An LLM may one day help extract a mandate draft from a photo; verification and execution are deterministic code, every time.
- Demo surface: a dependency-free Node http server — a buyer console (mandate card, hold, verdicts, receipts), the seller's public repair page (unguessable token, bound to that one invoice of that one mandate), and the intake demo.
- Intake: a deterministic quote parser (documented grammar) with an arithmetic cross-check. Photo/voice sources join the same function as extracted text; extraction may assist, verification never guesses.
Challenges we ran into
- Agents cannot "pay an invoice": there is no such PayPal endpoint, and a buyer-side agent cannot even read a third party's invoice. The settle pattern is therefore: verify the invoice document, then settle through Orders v2 — with the mandate's number carried as our own reference label, never as a PayPal invoice_id field (our merchant account rejects any invoice_id in the authorize chain as a duplicate; we learned this from three rejected Sandbox runs, and the field discipline is now written into the client).
- The official agent toolkit cannot authorize or partially capture the way the guardian needs — hence toolkit thinking for reads, raw REST for money.
- A credential-capture fault in our tooling kept the Sandbox secret from reaching the build machine intact (verified independently: the same credential authenticates when presented directly). The live runs therefore travelled the lane that keeps the secret on the owner's own device end to end — typed there, never stored, never transmitted to us — while the hosted demo surface runs the labelled mock backend. We would rather label a demo honestly than decorate it.
Accomplishments that we're proud of
- The repair link: the seller's correction is a first-class citizen, not a support ticket. The demo's climax is the seller's click — and the corrected document must still pass the same verification as any invoice.
- Evidence, not verdicts: the drift receipt accuses no one. It shows agreed, billed, and what changed — and invites a fix.
- A frozen mandate that actually verifies: tamper with one cent in a test and the hash check stops the money.
What we learned
Three-way matching is decades old in ERP; the unoccupied seam is buyer-side informal trade, where the agreement lives in a chat and the invoice arrives later from the counterparty. Binding those two documents to one hold — and giving the counterparty a door to repair drift instead of an argument — is a small idea that only exists in the seam.
What's next for Reconciliation Guardian
- The live settlement leg is proven: on 2026-11-08 two full Sandbox runs — order → buyer approval → AUTHORIZE hold ($200.00) → capture of the verified amount, read back COMPLETED from PayPal's own records — ran through raw PayPal REST. Remaining: run the same chain from the hosted demo surface once a credential route for the server exists.
- Photo/voice intake upstream (OCR/ASR → the same deterministic draft + cross-check).
- Dispute evidence pack export from the stored match record.
- Webhook listener (payment capture completed / dispute created) with postback verification and state re-reads.
Judge access notes
- Demo URL: https://recon-guardian.noprijbi99.workers.dev/
- Repository: https://github.com/noprijbi99-dotcom/recon-guardian
- Test flow (no account needed): open the demo URL → the mandate card is already frozen → "Open the hold" → "Simulate the seller's invoice" → follow the repair link → correct 260.00 back to 200.00 → watch the MATCH and the joined receipt.
- Backend labelling: the demo page states its backend on every screen. Note for honesty: the hosted demo defaults to the labelled mock backend; the live Sandbox runs (two completed $200 authorize→capture chains) were executed through the same raw REST calls the live backend makes.
