What does getting the pack out cost you today?
Accountants who close the month quickly do it by keeping the ledger current all month, so close is a confirmation rather than a catch-up. Most practices are not doing that, not because the people are slow, but because the transactions that should be landing in real-time are arriving as PDFs that wait for someone to open the accounts package and key them.
The result is a close that takes longer than the numbers justify, a pack that goes out later than the client expects, and a commentary that was drafted the day before it was due rather than when someone had time to think about what the numbers mean.
There is no non-vendor benchmark we could verify for how long a management pack typically takes to produce in an Irish practice. APQC publishes close-cycle data, but their own page returns an access error to us, the version available through a secondary source is eight years old, and the organisations it covers are not Irish accounting practices. We are not using it. What we ask instead: take the last three management packs you produced, note the date each one was requested and the date it went out, and count the questions from clients that followed each one. Those three numbers, taken honestly, tell you more about what the close costs than any industry average does.
What exactly gets automated?
Four things, and the fourth is where the quality lives.
Pulling the month's numbers from the ledger. On the agreed close date, the data is extracted, reconciled against the bank (the reconciliation workflow handles this separately) and formatted into the template. Not keyed. Not copied out of a report. Pulled, checked for completeness, and ready.
Building the pack to the fixed template. Profit and loss, balance sheet, aged debtors, aged creditors, the KPI row you agreed with the client when the engagement started. The same layout every month, so a client can read the March pack against the February pack without working out what changed between the formats.
Drafting the plain-English commentary against last month and against budget. Revenue up 12% on last month, the three largest items by variance, a flag where actual diverges from budget by more than the threshold you set. Not conclusions. The facts in plain words, organised so the finance lead can read them and either agree or rewrite in the five minutes before the pack goes out.
Flagging what moved and by how much, before the commentary is drafted. A list of the lines that changed by more than a set percentage or amount, with the prior period beside them. This is what stops the review from being a line-by-line check of a 30-row P&L. The reviewer is looking at eight things, not thirty.
When invoices arrive as structured data rather than as documents that need keying, the ledger is more current throughout the month and the close starts earlier because fewer items are outstanding at the end of it. As Revenue's phased e-invoicing programme extends to more businesses from November 2029 onwards, that will increasingly be the position for clients under the mandate. The detail on which clients and when is on the Ireland e-invoicing page.
What still needs a person?
Three things, and the second is the most important.
The review before the pack circulates. The finance lead reads the pack before a client sees it. Not a quick sign-off on a number that looks right. A read. The system produces a draft; the partner produces a pack. That sequence does not change.
The explanation of why a number moved. Revenue up 12% because a large client paid a retainer for six months in advance is a different sentence from revenue up 12% because three new clients started in the quarter. The ledger contains both facts. Which one goes in the commentary is a conversation with the client, not an inference from the data. This is Seán's ground, and any system that tries to write that sentence without talking to the client is making something up.
Accruals, adjustments and prepayments that require a decision. Some accruals are routine and the system handles them. Others depend on information that lives outside the ledger: an invoice not yet received, a project delivered but not yet invoiced, a dispute in progress. A person decides those, records the decision, and the system picks up the result.
How is the result measured?
Against three numbers, taken before the build starts and for three months back.
Days from close to draft in the finance lead's inbox. Not days from close to pack sent. The draft arriving quickly does not help if the review then takes a week. Measure both stages separately.
Rounds of correction before the pack goes out. A pack that goes through three rounds of "this number looks wrong" is a sign that either the data quality is poor or the template does not match what the client actually needs. Both are problems to fix before the build, not during it.
Client questions after the pack is received. Fewer is better, but zero is a concern rather than a goal, because it can mean the client has stopped reading it. Track what the questions are about: factual errors, missing context, or genuine analytical questions the client wants answered. The last category is what the pack is for.
Take three months of history on all three before anything is built. The comparison that matters is not against any published benchmark; it is against your own previous close.
What could go wrong?
Wrong numbers through a faithfully working system. If the ledger is not fully closed before the pull, the pack reports on an incomplete period. The system does not know the period is incomplete: it pulls what is there. The answer is a firm close date, agreed with whoever posts the final transactions, that the pull runs against. Changing the close date later is a configuration change, not a rebuild, but moving it between months is what creates the inconsistency.
Draft commentary that infers a cause the client has not told you. The system drafts commentary based on what the numbers say compared to last period. "Cost of materials up 18% month on month" is a fact the system can state. "Reflecting the increase in raw material prices since April" is not, unless the client told you that, because it might instead reflect a supplier change, a stock build or a keying error. The draft commentary states the facts. The finance lead adds the context. That sequence is not optional.
A template that no longer matches what the client agreed. Management accounts templates drift over the life of an engagement. A column added here, a KPI dropped there. If the template in the system does not match the template the client expects, the pack will look right and be wrong. A version-controlled template, reviewed at each annual engagement renewal, is the answer.
Accruals that become stale. A recurring accrual that made sense in January can be wrong by March if the underlying contract has changed. Someone reviews the accrual list on the same schedule as the close, not only when something looks wrong.
How long does it take to put in?
Two to four weeks, depending on the number of clients in the first wave and the complexity of the template.
A session on the template, the accruals that run automatically, the KPIs agreed with each client, and the close date discipline. A pull against the last three months of already-closed accounts, so the draft output can be compared to what went out. A review of the commentary drafts by the finance lead before anything is shown to a client. Then live.
Then we hand it over. No retainer, the template is yours to update, and adding a new client to the pack is a configuration rather than a rebuild. If you want to know whether this is the right first workflow to automate or whether something else on the list would move sooner, that conversation is the opportunity review, and it starts with the date your last three packs went out rather than with software.