The Back Office We Built to Run Our Own Business
One administration panel, built the same way we build for clients, solving the ordinary problems of running a services business, starting with a rule that refuses to guess whose deposit is whose.
Bank deposits arrived with almost nothing identifying who sent them.
Every deposit posts with only what the bank happened to capture: a merchant name that may or may not name the client, and an amount that on its own proves nothing. An amount matching an invoice is a coincidence until something else confirms it, and reconciling that by eye does not scale past a handful of accounts.
The back office we run our own business on needed the same discipline we build for clients: never post a match it cannot prove, and never leave a person guessing which reading is real.
A matcher that ties a deposit to an invoice only when nothing is left to guess.
A daily job compares every unmatched deposit's bank text and amount against the client's open invoices. A deposit only pays automatically when the bank text names that client and the amount matches exactly one open invoice; anything else is left in a queue with the reason attached, never auto-posted on a guess.
When a deposit's amount exactly matches one open invoice but is also exactly a combination of other open invoices for that client, the matcher will not pick a reading. A person decides. The same discipline applies to a deposit that repeats an amount already paid: nothing open explains it, so it waits for a person rather than being guessed at.
Watch it work on demonstration data.
A deposit that will not guess
Demonstration dataThis Money tab normally holds two more groups: charges waiting for a bucket, and proposals waiting for a yes. Here it shows only deposits waiting for an invoice.
This stage shows the Preisser Solutions back office matching bank deposits to open invoices. Deposits arrive, three are matched cleanly to a single invoice each, one amount matches an invoice exactly but also a combination of two smaller ones and is held rather than guessed, one deposit is still pending at the bank, one names no client the system recognizes, one matches no open invoice for its client, and one repeats an amount already paid and is left unexplained. The clients, invoices, and bank rows shown are an invented demonstration.
Before: a bank statement on one screen, a spreadsheet of open invoices on another, and a person cross-checking both by eye.
Bank statement: deposits
+4 more
Ledger: open invoices
+4 more
Deposits post from the bank, and the matcher decides on each one before a person ever sees it.
This deposit matches an invoice, but the amount is also two smaller invoices combined.
Three more deposits, three different reasons the matcher will not guess.
A deposit with no name on it.
Mobile Check Deposit for $640.00. The bank text names no client the system recognizes.
A deposit that matches no open invoice for its client.
LARKSPUR FENCE SUP, $1,500.00. No open invoice for this client is $1,500.00.
A deposit that repeats one already paid.
LARKSPUR FENCE SUP, $1,850.00. INV-2101 already paid this amount. Nothing open matches, so it is left for a person.
The Money tab's Review view, recreated: the deposits still waiting on a person.
The deposit-to-invoice matcher, the first proof stage of the back office.
A daily matcher that ties a bank deposit to an invoice only on a name match and an exact amount
A hold queue for anything the matcher cannot prove: a competing combination, no counterparty, no exact match
A repeat deposit against an amount already paid matches nothing open, and is left for a person, never re-paid
Outcomes the engagement actually produced.
The bank text has to name the client and the amount has to match exactly: a coincidence never posts on its own.
When a deposit's amount exactly matches one invoice but is also exactly a combination of others for that client, the matcher will not choose a reading and flags it for a person.
A deposit the matcher cannot place stays queued with its reason attached until a person decides.
Related case studies
FarmBooks: Photograph a Bill, Get Schedule-F-Ready Books
Photograph a farm bill; deterministic checks turn it into Schedule-F-ready books
NWKS Encounter: Nobody Retypes Anything
Executive visibility into the ministry, and 90% of the busy work automated
Want a back office that refuses to guess?
Preisser Solutions builds the administration panels and the automation underneath them. Scoping begins with a conversation about your sources and your decisions.