Order and Invoice Work as One Reconciled Loop
Orders, warranty claims, and shipping documents come in, get validated, and reconcile against the ERP, with human escalation on exceptions.
Connect the systems and define what a valid record looks like
Connect the payment and ledger systems the loop touches, Stripe and Square for orders and payments, Xero as the accounting ledger, and Ramp for spend. The run reads from all of them and reconciles across them.
Define validation in a playbook, a reusable, named set of steps: the fields an order must carry, how a warranty claim maps to an original sale, and what counts as a match against the ERP. This is the standard every record is held to.
Playbook: !reconcile-orders For each order, warranty claim, or shipping document: 1. Intake and parse the document; extract the key fields. 2. Validate: required fields present, amounts consistent, and it ties to a known customer or original order. 3. Reconcile against the ERP record, quantity, price, status. 4. If it matches, update the ledger and mark reconciled. 5. If it does not, hold it and escalate to a human with the exact mismatch and the two records side by side.
Warranty claims are where legacy data bites hardest. Give the run read access to the original sales records so it can tie a claim back to its purchase instead of taking the claim at face value.
Feed the loop from your intake channels
The loop runs itself when documents flow straight in. Point your order intake, claims inbox, and shipping-document feed at a run so each new document starts the !reconcile-orders playbook.
For legacy or batch systems, use a schedule instead: sweep the intake location on a cadence under Settings, then Schedules, and post the reconciliation summary to a finance Slack channel.
The sharp edge: shipping documents and orders often use different identifiers for the same transaction. Give the run the mapping between them up front, or it flags true matches as mismatches and floods the escalation queue.
Watch one warranty claim reconcile
Take a warranty claim that comes in against a months-old sale:
The run validates and reconciles across systems, and escalates only the genuine exception.
Claim: WC-5521, product SKU-7788, requested refund $340 Run actions: - Parsed the claim; matched SKU-7788 to original order ORD-11902 from four months ago (Square). - Validated: within the 6-month warranty window; customer and serial number match. - Reconciled against the ERP: original sale price was $310, claim requests $340. - Held the claim on the $30 overage; escalated with both records shown and the warranty terms cited. - Everything else this run: 41 claims auto-reconciled to Xero.
What the loop keeps in sync
When the run finishes, the order, claim, and shipping records tie out to the ERP, with exceptions surfaced, all verifiable:
Validated records updated in the ledger and marked reconciled. A short exception queue holding only records that failed to match, each with the mismatch named and the two records side by side. A cross-system reconciliation summary showing what tied out and what did not.
The side-by-side on each exception is the proof-of-work: a human sees exactly why a record was held, so clearing it takes seconds instead of a hunt across systems.
Sharpen the reconciliation
When the run keeps escalating a pattern you would auto-approve, add the rule to !reconcile-orders, or write it into memory (the notes a run recalls next time), like "restocking fees up to 10% on returns are expected".
As identifiers and formats drift across your legacy systems, update the field mapping so matches stay clean and the exception queue stays short.
The natural chain: route the spend side of these transactions into Procurement as a Governed Agent Run so purchasing and reconciliation share one governed loop.