Manage in-house bank accounts: what to automate, what needs a person, and what the data needs

Software can already run most of an in-house bank: posting internal transfers, netting, interest calculation and statements. People are still needed to approve intercompany loans, resolve unmatched receipts and handle exceptions in centralized payments. None of it works unless account master data, intercompany agreements and ledger mappings are clean.

What software handles well today

The mechanical core of an in-house bank is rules applied to balances. Once each subsidiary has an internal account and the rules are fixed, a treasury system can do this work without anyone touching it.

Internal payments between subsidiaries are the easiest case. One entity instructs a transfer and the system debits one internal account and credits another. It then posts the matching entries to both ledgers. Netting works the same way at scale. Positions are collected, offset by currency, and only the residual moves.

Interest and fees follow from value-dated balances and the agreed rate table. If the day count convention and the rate source are stored as settings, the calculation is deterministic. Statements are a report on top of all this. They can be generated and sent on a schedule.

Posting to the general ledger also belongs here. Transactions from the in-house bank subledger can flow to the ledger in detail or in summary, with adjustments routed for approval only when someone keys them by hand.

Where AI earns a place

AI adds value where the input is messy. Central collections are the clearest example. Customers pay into a group account and the remittance text is often partial, misspelled or missing. A model trained on past matches can propose which subsidiary and which open invoice a receipt belongs to. It can also recognise when a payment covers several invoices.

The proposal should come with a confidence level. High-confidence matches post automatically. The rest go to a queue. This keeps the model useful without letting it guess on the hard ones.

Models are also good at spotting outgoing payment requests that look unusual for a given subsidiary, such as a new beneficiary or an odd amount pattern. They flag. They should not block or release on their own.

Steps that still need a person

Intercompany borrowing involves judgement that does not reduce to rules. Someone has to weigh transfer pricing, withholding tax, local legal limits on lending and the currency exposure created. The booking can be automated after approval. The decision cannot.

Releasing payments on behalf of subsidiaries also stays with people, because signing authority is a legal matter. Software can prepare the batch, check it against limits and route it. A named approver still releases it.

Other work that needs a human:

• Researching receipts the model could not place, and deciding whether they are unidentified or simply misdirected.
• Handling returned payments and reversing the internal credit already given to the subsidiary.
• Settling disputes when a subsidiary challenges an interest charge or a fee.
• Signing off the in-house bank position at period end before the ledgers close.

What has to be true about the data first

Automation fails quietly when the master data is loose. Fix these before switching anything on.

Every subsidiary needs a defined internal account per currency, mapped to a specific intercompany account in its own ledger and in the treasury entity's ledger. If mappings differ between entities, the two sides will never reconcile without manual journals.

Intercompany agreements must exist as data, not only as signed documents. Rate basis, margin, day count, fee schedule and maturity need to sit in fields the system can read. A loan agreed by email and never recorded will be invisible to the interest engine.

Counterparty identifiers should be consistent across the group. The same subsidiary must not appear under different codes in different systems.

Value dates matter more than booking dates for interest. Check that every feed carries them.

The cut-off for internal transactions should line up with the group close calendar. Otherwise one subsidiary books a transfer in one period and the other books it in the next.

Finally, the in-house bank balance for each subsidiary should already agree with that subsidiary's intercompany balance. Automating on top of an unreconciled starting position just repeats the gap.

Questions to ask the people who run it

The documented process and the real one tend to drift apart. These questions surface the difference.

• Which subsidiaries still pay suppliers from local accounts, and why?
• When a receipt cannot be matched, where does it sit and who chases it?
• Are any loans or rate changes agreed outside the system and keyed in later?
• How often is a statement corrected after it has gone out?
• Who actually approves payment batches when the usual approver is away?
• What manual journals get posted at month end to make the intercompany accounts agree?
• Which spreadsheets exist that nobody has mentioned yet?

The answer to the last one usually points to where the real controls live. Any change plan should account for those spreadsheets before retiring them.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.