Everything in the box.
Four surfaces, one keyboard, and a written contract about what is allowed to change. This page is the whole product — including the parts that aren't built yet, and the parts we refuse to build.
30 capabilities built and running. Every one of them listed below, with its real status.
Nine client books. The exceptions lift out and collect into one queue — which is the entire product, in one object.
The product is four things.
Not a suite. One queue, one engine that fills it, one way the files get in, and one way to ask a question you can't answer from a spreadsheet.
The inbox
Every exception in every client's books, stacked in one list — uncategorized charges, cash shortages, tip drift, unmatched deposits. Not one tab per client. One list, worked top to bottom.
The same vendor landing uncategorized in seven restaurant books is one row, not seven. Confirm it once and it posts to all seven.
The reconciliation engine
The money that never touches the bank feed: tips owed versus tips paid, and the drawer versus the deposit slip. Computed nightly, per location, per business day.
No finding arrives without its evidence and its arithmetic. If the engine isn't confident it says “needs review” — it never states a number as a fact.
The report inbox
Every location gets its own private email address. Point the POS's existing scheduled report at it and ingestion is zero-touch — forever. Nothing is installed at the restaurant.
No API approvals to chase, no logins to collect, no scraping. A format we don't recognise is refused out loud, naming the offending lines — never parsed halfway and posted.
Ask the manager
Some answers only exist in someone's head at the restaurant. Press E and the manager gets a mobile page with no login and an expiry: “What was this $212 paid-out on March 14?”
Their answer and receipt photo land back on the finding. Unanswered ones chase themselves, so the question doesn't die in your sent folder.
Illustrations from demo data — the surfaces are real, the vendors, amounts and reference numbers are not. We're pre-launch; there are no customer books to screenshot.
Every capability, and its real status.
Status reflects what is built and running on main, as of 12 Aug 2026. Nothing here is aspirational; nothing here claims a customer count. We are pre-launch, and this table is how you can tell we'll say so.
The product as an assembly — 30 parts in place, 3 still hollow. It builds itself as you read the table.
| Capability | Status | Version |
|---|---|---|
| The inbox | ||
| Keyboard-first exception inboxJ/K navigation, single-key disposition | BUILT | V1 |
| Multi-book batch applyone vendor across every book at once | BUILT | V1 |
| Command palette (⌘K) | BUILT | V1 |
| Policy memoryyour firm's rules, visible and editable | BUILT | V1 |
| Reviewer modea second pair of eyes before the close | BUILT | V2 |
| Reconciliation | ||
| Cash over/short, dailyexpected deposit vs actual, per location | BUILT | V1 |
| Tip-liability rollforwardaccrued vs paid via payroll vs paid from drawer | BUILT | V1 |
| Deposit matching | BUILT | V1 |
| Cash-short pattern attributionwhich register, which shift | BUILT | V2 |
| Payroll clearing account reconciliation | BUILT | V2 |
| Delivery-payout reconciliationDoorDash · Uber Eats · Grubhub | BUILT | V3 |
| Processor fee audit | BUILT | V3 |
| Sales-tax-collected reconciliation | BUILT | V3 |
| Gift-card liability drift | BUILT | V3 |
| Intercompany due-to / due-fromrestaurant groups | BUILT | V3 |
| Getting the files in | ||
| Per-location private ingest address{location}@in.ledgerinbox.com | BUILT | V1 |
| POS report parsingToast · Square · Clover | BUILT | V1–V2 |
| Payroll journal parsingGusto · ADP · Paychex | BUILT | V1–V2 |
| Refusal-first parsingunrecognised format rejected by name, never half-parsed | BUILT | V1 |
| Evidence & write-back | ||
| Findings carry evidence and shown math | BUILT | V1 |
| Two-way QuickBooks write-back | BUILT | V1 |
| Idempotent, reversible postingclosed-period guarded; one-key batch reversal | BUILT | V1 |
| Ask-the-manager linksno login, expiring, self-chasing | BUILT | V1–V2 |
| Close certificateper client, per period, signable | BUILT | V1 |
| Post-close drift detection | BUILT | V2 |
| Branded monthly firm report (PDF) | BUILT | V2 |
| Firm & security | ||
| Per-firm database isolationrow-level security, deny-all by default | BUILT | V1 |
| Append-only audit logenforced in the database, not the app | BUILT | V1 |
| Firm activity consolewho did what, when | BUILT | V4 |
| Rolesowner · admin · member | BUILT | V1 |
| SSOOkta · Google · Microsoft | NEXT | — |
| SOC 2 Type II | NEXT | — |
| Support SLA | NEXT | — |
| 30 built·3 next | ||
SSO, SOC 2 Type II and the SLA are deliberately not started. They are gated on a firm with 25+ locations actually asking for them — building them before that is theatre, and we'd rather tell you than pad this table.
In, through, out.
Three inputs, one engine, one destination. Anything not on this diagram does not happen.
In
- QuickBooks Online · OAuth
- POS daily report · email
- Payroll journal · email
- Bank export · CSV or Plaid, optional
Through
- Cross-check · nightly
- Findings · evidence + math
- Your inbox · one queue
- Your keystroke · required
Out
- QuickBooks journal entry
- Audit row · append-only
- Close certificate
- Manager question · if escalated
What we never receive
- Bank login credentials
- Card or account numbers
- Guest or customer PII
- Employee social security numbers
- Anything from inside the restaurant's POS terminal
- Balances or account totals, for the categorization model
Nothing posts without a human keystroke. The engine proposes; a person confirms. There is no autonomous mode and there is no plan for one.
Every write is idempotent, logged and reversible, and is blocked outright if the period is closed in QuickBooks.
The model sees one line at a time — description, amount, date, and your firm's policy memory. Never balances, never client PII.
These keys are a published API.
The complaint that built this company was never “it's missing a feature.” It was “it moved.” So the keymap is versioned like an interface, not tuned like a preference.
Changing what a key does is a major version bump: a written rationale, a public changelog entry, thirty days of in-app notice, and the old key keeps working for all thirty. We've done it twice — both times to fix a binding the browser was silently swallowing, both written up in full. Read the keystroke changelog →
What we will never build.
This list is as load-bearing as the one above it. A tool that does everything is a tool that does none of it before the dinner rush.
| We don't do this | Because this already does it well |
|---|---|
| Daily sales journal entries | Shogo · Bookkeep. They post the entry; we reconcile what they post. Keep them — most firms run both. |
| Inventory, COGS, recipe costing | MarginEdge · Restaurant365. We stop at the ledger. |
| Practice management | Double · Karbon. We're the queue inside your close, not the system around it. |
| Financial reporting and dashboards | QuickBooks. It already does this, and you already know where it is. |
| 1099 filing · engagement letters · e-sign | Not our close. Adding them would make everything above slower. |
| White-label client portal | A portal your client never logs into is a feature you maintain for nobody. |
| Xero and other ledgers | QuickBooks Online only. Depth in one beats a shallow adapter in four. |
| Autonomous bookkeeping | Nothing posts without your keystroke. That's a boundary, not a roadmap item. |
Send one month. We'll show you the findings.
One client, one month of POS, payroll and bank files. We run the whole engine and send back what we found — the shortages, the tip variance, the unmatched deposits — with the math attached. Free, and yours whether or not you sign up.