Core to GL reconciliation for banks

Core to GL reconciliation confirms that account-level balances in the core banking system match the summarized balances in the general ledger. The two drift apart because the core tracks customer accounts while the GL tracks accounting balances, and they are linked by mapping rules, posting feeds and timing. A good process reconciles by product and cost center, explains each break, and fixes the mapping at its source.

Most banks reconcile core to GL daily or monthly. The work itself is rarely the problem. The problem is that the same breaks come back, because the fix lands in a spreadsheet instead of the mapping that caused it.

Why core and GL drift apart

1. Mapping rules. Each product and transaction type maps to GL accounts. New products, changed fee codes and conversions leave gaps.
2. Timing. The core posts in real time or in batches, while the GL closes on its own schedule. Cutoff differences show up as breaks that clear the next day, which teams learn to ignore until one doesn't clear.
3. Manual entries. Adjustments booked directly to the GL never touch the core, so they need their own trail.
4. Suspense and clearing accounts. Items parked in suspense can hide real breaks inside a net balance.

How banks reconcile today

1. Pull balances from the core and the GL at the same cutoff.
2. Match them by GL account, then drill into product and cost center.
3. Investigate breaks above a threshold and book corrections.
4. Document the cause, usually in a spreadsheet or a ticket.

Step four is where knowledge leaks. The cause is written down, but the mapping that produced it often stays the same.

What to look for in a reconciliation tool

Matching engines are good at pairing transactions. Fewer tools explain why a break happened or keep the mapping between core and GL as a governed definition. When comparing options, look at what each one stores, who maintains it and whether it fixes causes or only flags breaks.

• Spreadsheets. Manual matching and notes. Best for small banks and one-off reviews. The limit: knowledge lives with one or two people.
• Transaction matching software. Pairs and flags transactions at volume. Best for high-volume daily reconciliation. The limit: it flags breaks without fixing the mapping behind them.
• Close management platforms. Track reconciliation tasks and sign-offs. Best for an audit trail of the close. The limit: they organize the work but don't change the data.
• Context layer, such as Preql. Keeps mappings as governed, owner-approved definitions. Best for addressing recurring breaks at the source. The limit: it works alongside matching and close tools, not instead of them.

How Preql helps

Preql keeps mappings as shared definitions that business owners approve, with version history and audit trails. When a break traces back to a mapping, the fix is made and recorded in one place instead of in a spreadsheet note.

FAQ

How often should core to GL reconciliation run?

Many banks reconcile cash and high-volume products daily and everything else at least monthly.

Does a new core remove the need for core to GL reconciliation?

No. It resets the mappings, which is why breaks often rise after a conversion.