A ledger per client, and nowhere that holds the work

1. Your integration problem is upside down

Your clients have the ordinary version. A job system, an accounting file, a scheduling tool, a document folder, a spreadsheet, and nothing joining them but the office manager. You have seen it a hundred times and you have probably fixed it for a few of them.

A practice has the opposite problem, and it is worth naming clearly because the usual advice does not fit. You do not have six systems for one business. You have one very good system repeated across a book of businesses, plus a practice tool, a workpapers tool, a document collection tool and a mailbox. Your ledgers are not the mess. They are the cleanest thing in the building.

What is missing is a layer above them. No single ledger can tell you which client is behind, because being behind is not a fact any one ledger holds. It is a fact about the relationship between a client, a period, an obligation and whose turn it is. That fact has no home, so it lives in a spreadsheet and in the head of whoever owns the client, and it walks out the door when they go on leave.

This is why connecting things sideways never helps here. An integration joins two systems. Nothing about joining them builds the floor that is missing above them.

2. The spreadsheet is the missing system

Almost every practice has one. A tab per month or a row per client, columns for where each file is up to, colour coding that means something to two people, and a rule that only one person updates it. It is the most important asset in the practice and it is held together by good manners.

Do not be embarrassed about it. Its existence is a correct diagnosis. Somebody worked out that the state of the work needed a home and built the only home available. The problem is not the idea, it is the material. A spreadsheet cannot refuse anything, cannot tell you who changed a cell, cannot chase anybody, and cannot be read by two people at once without somebody losing an edit.

And it cannot answer the question the practice is actually built around: manage by exception. Show me only the files that are off track, with a reason and an owner. A spreadsheet can be sorted and filtered by a person who already knows the answer. That is not the same as a queue that surfaces the exceptions whether or not anyone thought to look.

The whole of this paper is one move: take that spreadsheet seriously enough to give it a floor to stand on.

3. What a floor actually is

Four things, and every one of them is boring, which is the point.

• A record. One place where a client is a client and a piece of work is a piece of work, each with a key issued by you, and each ledger’s own identifier sitting on the row as a column.
• A gate. Something that can refuse. A file cannot be marked ready for review with an unreconciled bank account. A period cannot be closed with an open query against it. This is the piece a spreadsheet can never be, no matter how well maintained.
• An argument. A report that reads the record directly and refreshes without anybody preparing it. If the Monday meeting needs somebody to build the status pack first, the meeting is about the pack.
• An identity. Who can see and do what, from the accounts you already administer. In a practice this matters more than most: client confidentiality is not a convention, and a contractor should see their clients rather than the book.

Record, gate, argument, identity. Every tool you have ever bought is those four things wrapped around one job, sold monthly, with its own login. Hold the four yourself and the tools become sources rather than places where knowledge hides.

4. The key is not the client

This is the one design decision that decides whether the build works, and it is the one most people get wrong on the first attempt.

The instinct is to key everything on the client, because that is how the practice thinks and how the billing works. It is not enough. A client is not in one state, they are in several at once: last quarter lodged, this month behind, payroll current, a query outstanding since August. Key on the client and you get a status column that has to lie, because it can only hold one answer to a question with four.

The key is the client, the period and the obligation. One row per thing that is actually due. That single choice is what makes the rest possible: a clock per row rather than per client, an owner per row, a blocked reason per row, and a queue that can genuinely be worked rather than reviewed.

It also changes the conversation with the client. “You are behind” is an argument. “These three things are waiting on you, and they have been since this date” is a fact with a date on it, which is a much shorter phone call.

5. The stack already under your feet

If the practice runs Microsoft 365, you are paying for all four already.

SharePoint lists are the record. Power Automate is the gate, and it is the good kind, because a person cannot type past a flow. Power BI is the argument, and this is where a practice gets the most immediate value, because a portfolio view is exactly the shape Power BI is good at. Entra is the identity, already administered by whoever set up your email, and it is how you give a contractor three clients rather than the book.

You do not have to like Microsoft for this to be the practical answer. The floor is already poured, already paid for, already inside whatever you tell clients about how their information is held, and it already survives a staff member leaving. That last one is the whole point in a business where the knowledge is the asset.

Two honest notes. Some of this steps up in cost once you need the premium tier of connectors, or Dataverse instead of lists, and a practice reaches that line sooner than a single business does, because reading a ledger through an interface is usually a premium connector. Price it before you design around it. The debtor chasing build plan carries that question with the lists and flows spelled out.

On Google Workspace the same four pieces exist under different names, and if you are on neither there is a page for free tiers. The argument is about the shape, not the brand.

6. What you build, and what you never build

Build the state of the work. The obligation register, one row per client per period per obligation. The query list, every outstanding question with who it is with and how long it has been there. The client readiness view, which files can actually be worked today and which are waiting on someone else. Onboarding and offboarding as checklists that refuse to be half done. Your review step, with the reviewer as a named person and not a colour. These are the parts where every practice is different, and where the off-the-shelf tool has always felt like wearing somebody else’s boots.

Never build the ledger, and never build the lodgement. Not because it is technically hard, but because being wrong there attaches to a registration and a professional obligation, and that is not something you generate on a Thursday. The systems that hold those were built around what an auditor and a regulator need to see.

Never store a number you could be wrong about. The floor reads balances, positions and lodgement status. It does not keep its own version. The moment your dashboard disagrees with a client’s ledger, the dashboard is the problem, and you will spend the rest of the year explaining it. One source for numbers, always, and it is not you.

One rule settles most arguments about where a thing belongs: organise by the question, not by the software. Not “what does the practice tool hold”, but “what do I need to answer on the second Monday of the month”. A register per question. The tools become sources, not locations.

7. The smallest version that is still a system

A first version here is not an app. It is one key, one register that runs on it, and one gate that can say no.

• The key. Two lists, clients and obligations, where the obligation row is client plus period plus type, and each ledger’s identifier is a column. That is the entire long game, and it costs an afternoon now or a rebuild later.
• One register. The obligation register, because it is the spreadsheet you already maintain and the one whose failure costs the most.
• One gate. A row cannot reach ready for review with an open query against it. It has to block, not warn.
• Numbers in one direction only. A nightly read of whatever status you can get cheaply, into a list, read-only, never written back. Start with fewer clients rather than a cleverer connection.
• One report. The exceptions view, and the test is that it refreshes without anybody touching a file.

Deliberately not in it: no client portal, no document collection rebuild, no time and billing, no workpapers, no two-way writeback, and no agent yet. The client portal is what everyone starts with and what kills the project, because a portal with nothing behind it is just another place to chase people.

8. Where this goes, once agents have a floor

This is why the idea is worth acting on now rather than five years ago, when the same four pieces already existed.

An agent with a login per client is not an assistant, it is a liability. It has to guess which file is authoritative, it cannot see the book, and every answer needs checking against a ledger. That is why so many attempts at this feel like a party trick. The problem was never the model. There was nothing coherent to point it at.

An agent with one floor can do real work. Which obligations are overdue and what each is blocked on. Which clients have been asked for the same thing twice. Which files went quiet after a query and never came back. Those are answerable because owner, clock and blocked reason are columns rather than conventions.

Three stages, and the first is already true.

• It builds the thing. You describe the register you have always wanted and have a working list, a form and a gate the same afternoon. This is not a forecast. It is what changed, and it is the reason to pour the floor now.
• It maintains the thing. The agent reads the floor and notices where reality has drifted from the design. A register nobody has touched in six weeks. A gate people have found a way around. A field that is always blank, which means the process it described is not the process being run.
• The book gets managed by exception, properly. This is the one to aim at, and it is what a practice has always claimed to do while actually doing it by memory and diligence. When every obligation has an owner and a clock on one floor, the partner question stops being “how are we tracking” and becomes “show me only what is off track and who it is waiting on”. The work left for people is the judgement, which is what you charge for.

That end state is not a product anybody sells. It is a consequence of having a floor.

9. The discipline that has to arrive with it

Here is the trap, and you have probably already met it from the other side.

If an agent can regenerate the whole thing from a prompt, you do not have a system. You have a slot machine. Ask again and it comes back different, and every check you did last month has to be done again from scratch, because nothing is the same shape any more. Practices are meeting this from the client side already: a client builds something themselves, you find the errors, they re-prompt, and what comes back is not a correction but a new and different thing that has to be reviewed from the beginning. The review hours are yours and so is the exposure.

Which is the argument for building your own floor properly rather than not building one. The fix for regeneration is a fixed structure and a diff, not abstinence. The build, buy or have it built paper works through that decision properly.

So the floor carries the parts that do not regenerate.

• The objects and their keys. A client is a client and an obligation is an obligation, with one key, forever. Agents can write the screens, propose the flows and draft the reports. They do not get to redefine the obligation.
• Gates that refuse rather than warn. A warning is a suggestion, and in the last week of the month half the team will read past it, correctly, because it was only a suggestion.
• A log. Who did what, when, and what the state was before. Not for suspicion. For the day a client or a regulator asks, and the answer needs to be a record rather than a recollection.
• A named owner on every queue, and a clock. The fastest way to tell a real system from a demo: point at any overdue row and ask whose it is and when it went overdue. If the answer is in somebody’s head, it is not a system yet.

Get those four right and the agents can be as creative as they like above them, because they cannot break the shape. Get them wrong and the more capable the agent, the faster the mess arrives.

10. The first step, and what stays with a person

One spreadsheet, moved. You already know which one.

It is the file that would stop the practice tomorrow if it were deleted tonight. Put it on the floor with the same columns and the same person maintaining it, re-key it so a row is a client and a period and an obligation rather than a client, and give it one rule it can enforce that the file could not.

It pays the same day. Two people can work in it at once, nobody asks who has it open, and nothing gets lost when the person who owns it takes a week off. And the first time the list refuses a row somebody wanted to close, you will have felt the difference between a file and a system, which is worth more than being told about it.

Then stop. Do not build a second register until people have stopped emailing the old file around. The failure here is never technical, it is two registers running in parallel through a quarter. Two weeks later the measure is simple: nobody has asked for the spreadsheet back, and at least one row got refused.

What stays with a person. The judgement and the advice. The review, and the name on it. Any treatment a client could act on financially. Anything that would imply an opinion you have not formed. A floor makes the state of the work visible. It does not form a view, and it should never look like it has.

And the one thing no floor can give you: the live phone call. A register can tell you that three clients have been sitting on the same request for a fortnight, and that a debtor book across the whole book of clients has gone quiet. It cannot make the calls. That needs a number, a carrier, calling hours, the disclosure spoken at the top, a Do Not Call check before the dial, and a recording and transcript kept where somebody can read them later. That is not a feature you generate. It is the one row in the whole build that never goes to zero, and it is the part we run: Get Paid on Office Voice makes the debtor call in your client’s name, off their live Xero, and writes the promised date back to the invoice.

Everything else on this page you can build yourself, and now you can build it in an afternoon. That is the honest shape of it, and it is why the standards on this site are published rather than sold.