Skip to content
All case studies
AI infrastructure Operational agent E-commerce ops

The numbers reconcile before anyone is awake

Orders, payments and fulfilment lived in four systems that quietly disagreed. Built a nightly agent that reconciles them, classifies the variances, and posts the exceptions to Slack before the team logs in.

Nightly

unattended, before the working day

Caught early

variances surface before the customer complains

Plain language

an exception report a person can act on

Owned

each exception lands with a suggested owner, ready to act on

The client

An online retailer where the storefront, the payment processor, the data warehouse and the third-party logistics provider each held a version of every order, reconciled by hand when something looked off.

The problem

When the storefront, the processor and the 3PL disagreed on an order, nobody knew until someone reconciled them by hand, usually after a customer complained or at month-end. A captured-but-unshipped payment or a refund that never reached the books could sit for days. The fix was something that checks every night and speaks up only when it should.

How it ran

Scheduled, unattended, and quiet on a clean night.

Step 1

Triggered nightly

A scheduler runs the agent every night with no one pressing a button.

Step 2

Four sources, one check

Storefront orders, processor settlements, warehouse records and 3PL shipments are pulled and matched on the order key.

Step 3

Variances classified

Each break is bucketed: timing, mapping, genuine error, or known and accepted.

Step 4

Exceptions to Slack

A short plain-language report lands in the channel. A clean night says so in one line.

Step 5

Learns the edges

A new accepted edge case becomes a codified rule, so it does not page anyone twice.

What I did

  • 01.Built the reconciliation logic between storefront orders, processor settlements, warehouse records and 3PL shipments on a shared order key.
  • 02.Wrapped it in a scheduled, serverless run so it executes nightly with nobody attending it.
  • 03.Added a classification step that sorts each variance into timing, mapping, genuine error, or known and accepted.
  • 04.Generated a plain-language exception report posted to Slack, written so a non-technical reader can act on it.
  • 05.Made a clean night explicit: one line saying everything tied, so silence is never ambiguous.
  • 06.Maintained it on retainer: accepted edge cases get codified so the same break does not fire twice.

Under the hood

How it stays trustworthy

  • Matching is deterministic SQL. The order-key match and the timing and known-accepted buckets are rules; the model has no hand in deciding whether something reconciled.
  • The model only narrates. It writes the plain-language exception and the suggested owner; it cannot mark a break resolved.
  • A clean night is explicit. The run posts an "all tied" line, so a job that failed to run is itself detectable.

What it will not do

It will not adjudicate a money difference, and it will not stay silent on a clean night. The model never decides the books; it only describes what the deterministic check found.

InteractiveSee it run

Run last night's reconciliation

Sample figures, illustrative only
Pull orders Pull payments Match to fulfilment Post to Slack

Result

What the team woke up to.

Breaks found early

A captured-but-unshipped order or a missing refund is flagged the next morning, not discovered by a customer.

Manual recon gone

The month-end hand-reconciliation is replaced by reading a short report and acting only on exceptions.

An audit trail

Every night's result is recorded, so "did order 80213 ship and settle" has an answer.

It gets quieter

Accepted edges become codified rules, so noise drops over time instead of rising.

Built as a fixed-scope engagement, then maintained on retainer so the checks keep matching reality. The deliverable includes your team able to run and extend it after the engagement ends.

Tools used

BigQuery Cloud Functions Cloud Scheduler Python Slack API Claude

Reconciling orders by hand?

It usually starts as a short Spotcheck to size the work, then a fixed-scope build, then it is maintained on retainer so the checks keep matching reality.