Treasury controls: the four reconciliations every CFO should automate

There is a pattern in treasury fraud cases that anyone who has run an internal audit function long enough has seen at least twice. The fraud does not happen on the 15th of the month. It happens on the 30th or the 31st. The treasury accountant who normally reconciles bank statements daily is sitting in the close-the-books meeting until late evening. The bank reconciliation for the last working day of the month does not get run that night. The next morning, it gets pushed to the following week. Three weeks later, somebody notices an outstanding item that does not clear, and the trail is already cold.

This is not a clever scheme. It is the predictable outcome of a process that depends on a person being attentive at the moment when they are most overloaded. The fix is not better people. It is automation of the four reconciliations that should never sit on a person's manual workload.

Why treasury is structurally exposed

Treasury sits between the bank and the books. Every cash movement passes through it. Most of the controls are designed around two-person authorisation — maker, checker, payment release — and most treasury fraud cases involve a breakdown in either segregation of duties or reconciliation discipline, not a breach of the authorisation flow itself.

The 2024 ACFE Report to the Nations puts the median loss from billing schemes and cheque-and-payment-tampering schemes at the high end of asset-misappropriation losses — meaningfully higher than expense-reimbursement or payroll fraud. Treasury is where the larger numbers live, and the longer the detection time, the larger the loss.

The four reconciliations

Four reconciliations carry the operational weight of the treasury control environment. Each one fails most often at month-end. Each one is automatable to a degree that removes the human bottleneck.

Reconciliation one: bank-to-book daily

The cornerstone. Every bank account, reconciled to the corresponding ledger account, daily. Not weekly. Not at month-end.

The manual version of this reconciliation is what fails. The treasury accountant downloads the bank statement, opens the cash GL, and matches transactions line by line. On a low-volume day this takes 30 minutes. On a high-volume day, particularly month-end, it takes three hours, and the temptation to push it to tomorrow is constant.

The automated version uses the bank's MT940 statement feed or a direct API integration with the bank to pull statement data into a reconciliation engine — Kyriba, HighRadius, BlackLine, or a well-built in-house Power BI model. The engine auto-matches against the GL using transaction reference, amount, and date. Unmatched items surface on a dashboard. The treasury accountant reviews exceptions, not every transaction.

On a portfolio of 12 to 20 bank accounts with 200 to 500 daily transactions, the manual version is a half-day exercise. The automated version is 30 minutes for exception review. The exception list is the actual control. The matched transactions are noise.

Reconciliation two: intercompany matching

For groups with multiple legal entities, intercompany balances are the second-most-common location of reconciliation breakdowns. Entity A invoices Entity B for services. Entity B records the corresponding payable. At month-end, the balances should equal. They often do not, by amounts that range from rounding differences to material discrepancies.

The root causes are mundane. Different exchange rate conventions, timing differences in posting, GST treatment differences, and occasionally an invoice that was posted on one side but not the other.

The automated version of this reconciliation runs nightly, on a unified intercompany subledger, with matching by transaction reference and amount. Any imbalance above a defined tolerance creates a queue item for the entity accountants to resolve before month-end. The manual version, in which the consolidation team chases imbalances on day five of the close, is where errors persist.

For mid-size groups, the cost of automating intercompany matching is low — most ERP packages now support it natively. The cost of not automating it is the closing time penalty and the recurrence of unresolved items from prior periods.

Reconciliation three: FX revaluation

Every entity with foreign-currency exposure — payables in USD, receivables in EUR, USD-denominated loan, hedge contracts — has to revalue those positions at month-end at the closing rate, and recognise the gain or loss in P&L or OCI as the accounting policy dictates.

The manual version is a spreadsheet that pulls open balances, applies the closing rate, and computes the revaluation entry. The errors are predictable. Hedge accounting positions that should not be revalued the same way as unhedged positions. Forward contracts that were settled but not removed from the spreadsheet. Closing rates pulled from inconsistent sources — interbank rate, RBI reference rate, the company's bank's mid-rate — without documentation.

The automated version uses a treasury management system or an ERP module that maintains the FX positions, applies the documented rate source, and generates the revaluation entry. The treasury accountant reviews and approves the journal, rather than building it.

The accounting auditor's question on FX revaluation is almost always the same: which rate, sourced from where, applied to which open balance? When the answer is 'the spreadsheet pulls it from somewhere', the audit query becomes a multi-week exercise. When the answer is 'the TMS sources the RBI reference rate via API at 5pm IST and the policy document is here', the query closes in one meeting.

Reconciliation four: cash forecast vs actual

The fourth reconciliation is the one most CFOs do not think of as a reconciliation. The cash forecast, prepared at the start of the month, is compared to the actual cash receipts and disbursements as the month progresses. Variances are explained.

This is a treasury operating control, not an accounting reconciliation, but it serves a similar purpose. It surfaces unusual cash movements early, before they accumulate into month-end surprises. A receipt that was forecast and did not arrive raises a flag — the customer is late, or the invoice was disputed, or the cash was misposted. A disbursement that occurred but was not forecast raises a different flag — an approval went around the standard process, or a vendor was paid earlier than the policy required, or an unauthorised transaction has occurred.

The automated version uses a forecasting tool that integrates with the receivables ageing, the payables ageing, the loan schedule, and the payroll schedule. Variances above a defined tolerance trigger an inquiry. The treasury head reviews a one-page exception report each morning.

The fifth reconciliation that India adds: GST input credit

Indian context adds a fifth reconciliation that does not appear in textbook treasury frameworks. GST input tax credit sitting in the electronic credit ledger has to be reconciled monthly against the input credits claimed in GSTR-3B and the credits available per GSTR-2B (which reflects suppliers' GSTR-1 filings).

Mismatches occur because suppliers file late, or because invoices were booked in one period and the supplier filed in a different period, or because a supplier's GSTIN status changed. The mismatch determines whether the input credit is available, blocked, or at risk of reversal.

For exporters and SaaS firms with significant input credit accumulation, this reconciliation directly affects the cash trajectory of the GST refund. A monthly automated reconciliation, with supplier-by-supplier flagging, prevents the surprise that would otherwise arrive when the refund application is rejected.

What automation actually costs

Treasury automation costs are no longer the obstacle they were five years ago. Kyriba and HighRadius are enterprise-grade but priced at enterprise scale. For mid-market Indian companies, the practical options are SAP TMS, Oracle Treasury Cloud, or in-house Power BI dashboards integrated with the bank's statement feeds.

An in-house Power BI dashboard, built on MT940 feeds and ERP exports, can cover three of the four reconciliations — bank, intercompany, FX — at a build cost of two to three months of a treasury analyst's time, plus a Power BI specialist for two weeks. The fourth, cash forecast, requires either a treasury module or a separate forecasting tool.

The total spend for a mid-market group is in the range of ₹15 to ₹40 lakh upfront and ₹3 to ₹6 lakh annually for licensing. The return is the elimination of the month-end risk window and the freeing up of two to three days of treasury team time per month.

What we audit when we audit treasury

Three things, in order.

First, the documented reconciliation policy. What is reconciled, by whom, at what frequency, with what review.

Second, the evidence that the policy is operating. Bank reconciliations for a sample of dates, including month-end. Intercompany imbalance logs. FX revaluation working papers. Cash forecast variance reports.

Third, the segregation of duties around payment release. The maker, checker, and bank-token holder should be three different people. The same person should not hold all three roles. This is where the actual fraud risk concentrates, and the reconciliation discipline is what catches it after the fact.

The CFO's question to ask the treasury head is simple. 'If the bank reconciliation does not run for three working days, will you know?' If the answer is yes, the system is automated enough. If the answer is 'somebody would probably notice', the system depends on attention at the worst possible moment to provide it.

What the audit committee should see

A one-page treasury dashboard, monthly. Four numbers.

Unreconciled bank items older than 7 days, by account.

Intercompany imbalances above tolerance, by entity pair.

FX revaluation entries posted, with rate source confirmation.

Cash forecast variance for the prior month, with explanation.

If those four numbers are clean every month, the treasury control environment is operating. If any one of them is missing or stale, the audit committee has its question for the meeting.