Case study
The last system the firm rented.
Invoicing ran on a general-purpose work platform the firm had long outgrown, with the ledger reconciled by hand every cycle. Bringing it in-house was the last piece of the programme, and the one that had to coexist with everything already built.
Who built this
MatterCounts was built by the firm's own in-house development team, not by us. It is described here because the boundary between it and the systems on this page was a real piece of work, and because a programme that accounts only for its own deliverables is not an honest account of how the firm operates.
What it replaced
Invoicing, account summaries and the client-facing billing record had grown onto a general-purpose work platform alongside everything else the firm did. Every cycle, someone reconciled its numbers against the practice management system by hand — and when the two disagreed, which was routine, the difference was chased down one client at a time.
What the in-house system does instead
- Time and expense entries, trust and retainer balances, work in progress
- An invoice approval queue — draft, submit, approve, generate and send — rather than one irreversible action
- Credits and refunds carrying the payment gateway's own reference numbers
- Delivery to the client by email and text, with the account summary alongside the invoice
- A minimum-retainer figure, and the exact amount owed to bring an account back to good standing
The part that concerned us
Two systems were now in a position to write to the same client trust ledger — ours posting deposits as payments arrived, theirs posting them as invoices were settled. The practice management platform carries no external identifier on those records, so there is nothing to deduplicate on. Two writers would have silently doubled a trust balance.
Doubling a trust balance is not a defect you fix next sprint. It is a compliance problem involving client money.
One writer per rail. It is a single sentence, it takes ten minutes to agree, and it is the difference between two systems coexisting and two systems corrupting a ledger.
How the cutover ran
In parallel, for weeks. The new system generated invoices while the old platform still sent them, and the two were compared client by client until they agreed. Delivery state was synchronised in both directions specifically so that no client could be sent the same invoice twice during the transition.
Where they disagreed, the disagreement was the deliverable. One recurring gap traced back to a minimum-retainer rule the old platform applied and the practice management system did not — exactly the kind of thing that stays invisible until two systems are forced to produce the same number.
Want to know whether this applies to your firm?
Thirty minutes, an honest read on where your friction actually is, and a recommendation. If we are not the right fit, we will tell you.
Book an Operational Strategy Call