Accruals and prepayments when the system posts them

Accruals and prepayments are where automation looks obviously right and turns out to need more care than anything else in the close.

Obviously right, because the mechanics are pure repetition: release one twelfth of the insurance prepayment, accrue the estimated utilities, reverse last month's accrual. No judgement in the execution.

More care than expected, because an accrual is an estimate about the world, and the world changes without telling your ledger.

What should absolutely be automated

Prepayment releases. You paid twelve months of insurance. Releasing one twelfth monthly is arithmetic. There is no reason for a person to post it, and every reason not to — manual release is where months get missed and the amortisation quietly drifts.

Accrual reversals. Last month's accrual reverses this month. Mechanical, and forgetting it is one of the most common close errors in manual processes.

Depreciation. A schedule and a policy. Nothing to decide monthly.

Recurring accruals with a known basis. Rent accrued on a lease with fixed terms. The number is known.

Automating these removes a category of error entirely — the missed reversal, the forgotten release, the month where depreciation was not run.

Where it gets dangerous

The dangerous case is the estimated recurring accrual — the one where the amount is a judgement that gets repeated.

You accrue RM 6,000 monthly for utilities based on last year's average. The system posts it faithfully every month. Eighteen months later you have moved to a smaller unit, energy prices have changed twice, and the accrual has been RM 6,000 every single month throughout, because nobody was assigned to question it.

The error compounds silently. Each month is individually small and defensible. The cumulative difference is not, and it typically surfaces at year end when someone reconciles the accrual account and finds a balance nobody can explain.

This is the characteristic failure of automated accruals: not a wrong posting, but a right posting that stopped being right.

The control that fixes it

Every recurring accrual needs three things attached to it:

A basis. Not just an amount but why that amount — "average of last six months' invoices", "1/12 of the annual contract value", "estimated from the meter reading". An accrual with no recorded basis cannot be reviewed by anyone except the person who set it, and they will eventually leave.

A review date. An explicit point at which someone confirms it is still appropriate. Quarterly is usually right. Without a date it is never reviewed, because nothing prompts it.

An owner. A named person, not "finance".

Systems that let you attach these to the recurring entry make the review possible. Systems that only let you schedule an amount are storing up the problem.

The reconciliation that catches it anyway

Even with reviews, reconcile the accrual and prepayment accounts properly every month — not just confirm they have a balance, but confirm the balance is made of identifiable items you can name.

An accruals account with a balance of RM 43,180 that nobody can decompose is a warning. It usually means accruals have been posted and not reversed, or estimates have drifted, and the difference has been sitting there for some time.

This is the same principle as full traceability in reconciliation: the balance is only meaningful if you can say what it consists of.

What AI adds beyond scheduling

Flagging drift. Comparing the accrual to the actual invoices that eventually arrive, and surfacing when the gap has been consistently in one direction. If the utilities accrual has been RM 6,000 against actuals averaging RM 4,100 for five months, that should surface without anyone asking.

Proposing the basis. For accruals derived from actual history, the system can propose the estimate rather than repeating an old one — with a person confirming.

Catching the missing reversal. Not by scheduling it, which is trivial, but by noticing that a balance is behaving as though a reversal did not happen.

The first of those is the valuable one, and it is the specific answer to the failure mode above. Ask any vendor whether their system compares accruals to actuals over time and surfaces persistent variance. Many schedule; fewer compare.

Where a person is still required

Whether the accrual should exist at all. The contract ended, the service stopped, the dispute means the liability may not crystallise. These are facts about the business, not the ledger.

Year-end judgement. Whether an accrual is sufficient, whether a provision is needed, whether something should be disclosed. Unchanged, and unchangeable.

Anything unusual. A one-off accrual for a specific event should not be automated; it is not recurring by definition.

Common questions

Should accruals be automated?

Mechanical ones should be — prepayment releases, accrual reversals, depreciation, and recurring accruals with a known contractual basis are pure repetition, and automating them removes common errors such as missed reversals and forgotten releases. Estimated recurring accruals can be automated too, but only with a recorded basis, a scheduled review and a named owner, because the risk is not a wrong posting but a right posting that stops being right.

What is the biggest risk with automated accruals?

Drift. An estimated accrual posts faithfully every month while the underlying reality changes, so each individual month looks defensible and the cumulative difference does not. It typically surfaces at year end as a balance in the accruals account that nobody can explain, which is why comparing accruals to the actual invoices that eventually arrive matters more than scheduling them accurately.

How often should recurring accruals be reviewed?

Quarterly is usually appropriate, and the review needs to be scheduled with a named owner because nothing else will prompt it. The review should test the basis rather than the amount — whether the reason the accrual exists still applies and whether the method of estimating it still reflects reality.

How do I know if my accruals have gone wrong?

Reconcile the accruals and prepayments accounts monthly and confirm the balance decomposes into identifiable items you can name. A balance nobody can break down usually means accruals have been posted without reversing, or estimates have drifted from actuals over an extended period, and in either case the difference has been accumulating unnoticed.

Related: closing the books with AI assistance · year-end adjustments and the audit file · what full traceability actually means