How an accounting firm replaced its software stack

An accounting firm's software stack is usually five products: a ledger, a practice-management tool for close checklists and tasks, a client portal, a document-collection app for receipts and statements, and an e-signature service. We replaced all five with one platform because the cost that finally mattered wasn't the five subscriptions. It was the handoffs between them: every receipt that had to be matched by hand, every close task that had to be checked in a second tool, every client question that lived in an email thread none of the five could see.

We run an accounting firm. This is the practical version of that decision: what the stack was, what it charged, what broke, and what we'd tell a firm looking at the same move. The founder's version is in why an accounting firm built its own Financial OS.

The stack as it was and what each piece charged per client

Our stack was ordinary, which is the point.

The ledger. QuickBooks Online, one subscription per client entity, billed to us on the wholesale program or to the client directly. Competent at being a ledger. Our bookkeepers knew it well.

Practice management. A close checklist and task tool, billed per user. It knew which tasks were done. It didn't know whether the bank account actually reconciled; someone checked the box.

Client portal. Where the client uploaded statements and signed the engagement letter, billed per client or per firm tier. It held files. It didn't know which transactions the files belonged to.

Document collection. A receipt-and-statement fetching tool, billed per client. It pulled documents and pushed them to the ledger with a suggested coding. When the fetch broke, which was often, someone chased the client by email.

E-signature. A per-envelope or per-seat subscription for engagement letters and 8879s.

Per client per month, adding the five together at the tiers we were on, the stack ran somewhere between $60 and $110 depending on the entity count and which tools the client touched. That's before staff time. Every tool was reasonable on its own. Every tool was also a separate login, a separate client list to keep in sync, and a separate place a task could fall.

The per-entity price increase that forced the decision

The trigger was arithmetic. Our real-estate and multi-entity clients each had four to twelve LLCs, and the ledger billed per entity. When the ledger's price went up again, a client with nine LLCs got a nine-times increase, and there was no consolidated view across them anyway; the roll-up was a spreadsheet we rebuilt every month. We were paying more, per entity, for a product that didn't understand entities.

We wrote out what the stack cost per client per month, including the hours our staff spent moving information between the tools, and the number was uncomfortable. The per-entity math is in multi-entity bookkeeping without a subscription per LLC. The rest of this article is what changed when we stopped paying it.

What one client record changes about the close

The close is where the seams cost the most. In the old stack, closing one client meant: reconcile in the ledger, check the reconciliation box in the practice tool, look in the document tool for the receipts that came in, look in the portal for the statement the client uploaded, email the client the questions, and wait. Five tools, one close, and the status lived in the bookkeeper's head.

With one client record, the close is a board. Each client shows its reconciled balance per account, its Uncategorized total, its outstanding receipt requests, its open questions, and who has the file, all from the same data the ledger holds. Nobody checks a box; the number is either zero or it isn't. The reviewer reads the numbers a day later. The partner sees sixty clients on one screen and knows which closed by the 6th.

Three concrete things changed:

• Receipts stopped being a separate system. A transaction over the client's threshold with no document triggers the request; the client answers from the portal; the document lands on the transaction. No matching step.
• Client questions stopped living in email. The batched question list goes out once per close through the portal, with the transactions attached, and the answers post back to the lines they're about.
• The statement became the record. Instead of a fetching tool pulling a PDF that a person then compared to the feed, statement import reads the bank's own statement, proves it against its printed totals, and ties every line to the ledger. Reconciliation became a list of exceptions.

The e-signature and the engagement letter moved into the same client record too, so the 8879 and the letter are on the client, not in a separate envelope system.

Running our own clients on it first

We put our own firm on the platform before anyone else. That was partly necessity and mostly the only honest way to build it. Our bookkeepers hit every gap first: the statement format from a regional bank that didn't parse, the check-image match that guessed wrong on a handwritten payee, the rule that coded a loan payment to Materials. Each one got fixed because it was costing us hours, not because a customer filed a ticket.

It also set the standard for what "done" means. A feature isn't finished when it works in a demo. It's finished when our team runs sixty clients' closes through it without going back to the old tool. Several features didn't survive that test in their first version and were rebuilt.

The trade-off is real: a firm that builds its own software is running two businesses, and we've made mistakes a pure software company wouldn't have. What we have that a pure software company doesn't is the daily use.

What we'd tell a firm evaluating the same move

Four things.

Count the handoffs, not the subscriptions. The licenses are the visible cost. The hours between tools are the real one. Track a close for one client, by step, and count how many times information moves from one system to another by hand.

Per-entity pricing is a tax on your best clients. If the ledger bills per entity, the clients with the most entities are the ones being priced out of good bookkeeping. Whatever you move to should treat entities as a dimension of one client, with a roll-up that isn't a spreadsheet.

Don't move a late close. A firm whose close is running on the 20th will move that problem to the new platform intact. Fix the cadence first, then migrate, one client group at a time, starting with the ones whose books are clean.

Give competitors their due. QuickBooks Online is a good ledger. The practice tools are good at tasks. The document fetchers work when the connection holds. The case for one platform isn't that any of them is bad; it's that five good tools with seams between them cost more than the sum of their prices.

Where the platform comes in

Woven is our product, and it is the replacement described above: ledger, close board, client portal, receipt and statement collection, batched questions, e-signature, and multi-entity roll-up on one client record, with statement import that reads the bank's own PDF and categorization rules learned from the bookkeeper's first choice. Firm pricing is per client, at $39, $32, or $25 a month depending on volume, and bank connections are free, so a client with nine LLCs is one client. We run our own firm on it. To see the close board and the client record on live books, book a demo.