UPSCash: reconciling end-of-day cash against QuickBooks

UPSCash is one of my favorite kinds of project — small, sharply scoped, and genuinely useful. I built it in about two weeks for a client in the US who runs a chain of department stores, and it’s been quietly doing its job since.

The business problem

At the end of each day, every store has some amount of cash left in the register. The owner needs to know that amount and check it against what their accounting shows — not the day’s sales, just the cash sitting in the counter. And when a manager periodically deposits that cash to the bank, the owner wants to confirm the deposited total lines up too. Doing this by hand across many stores is exactly the kind of thing that quietly leaks money.

What I built

A full-stack app (NestJS + React) that:

• Lets store staff submit the day’s cash total.
• Connects to QuickBooks Online over Intuit’s OAuth 2.0 and pulls the relevant journal entries.
• Reconciles the two, per store, against configurable thresholds — a minor difference (default $100) is noted, a major one (default $500) emails the owner immediately.
• Runs the same check weekly on the manager’s deposit, escalating anything beyond a small tolerance as a red flag.

Reconciliation runs on a daily schedule, and there’s a manual trigger for a date range when someone wants to re-check.

The parts worth mentioning

Because this touches money and a third-party financial account, I spent most of the care on the boring-but-important things:

• QuickBooks tokens are encrypted at rest with AES-256-GCM and auto-refreshed before expiry.
• Webhooks are HMAC-verified and de-duplicated so a replayed event can’t double-process.
• Role-based access (admin / manager / employee) gates what each person sees and does.
• Audit logging records every reconciliation action — status changes, notes, views — with who, when, and old/new values.
• Encrypted backups with integrity checks, so the reconciliation history can be restored.

The QuickBooks client itself is rate-limited and queued with exponential-backoff retries, because Intuit’s API will happily throttle you otherwise.

Stack

NestJS + TypeScript on the backend, React on the frontend, SQLite via TypeORM for storage, Resend for the notification emails, and Docker for deployment. The whole thing is one tidy service.

What I took away

Two weeks, one clear problem, one measurable outcome: the owner stopped manually cross-checking registers and gets an email only when a number is actually off. I like these projects because there’s nowhere to hide — either the cash matches the books or it doesn’t, and the software has to get that right.