General Ledger Account Reconciliation Policy: What to Include

A general ledger account reconciliation policy is the internal control document that states which general ledger accounts must be reconciled, how often, by whom, what evidence counts as support, who reviews the work, and how long it is retained. It exists so that reconciliation is a defined control with an owner rather than a habit that depends on whoever happens to be in the closing rota. Auditors ask for it by name, and a policy that only says "accounts will be reconciled monthly" fails on contact with the first real question.

Last updated July 2026.

Most finance teams reconcile far better than their policy describes. The reconciliations happen, the differences get resolved, and the close lands. The policy is a two-paragraph inheritance from a previous controller that nobody has opened since. That gap is survivable right up until turnover, a first audit, a diligence process, or a difference nobody can explain, at which point the absence of a written standard turns a routine question into a finding. What follows is what a usable policy actually has to say, with the account tiering and evidence standards that make it enforceable.

What is a general ledger account reconciliation policy?

It is a control document, not a procedure manual. The distinction matters. A procedure explains how to reconcile the bank account in your particular system, and it goes stale every time you change software. A policy sets the standard the reconciliation has to meet regardless of the tool: which accounts are in scope, what frequency each one requires, what has to be true before the account is considered reconciled, who is allowed to prepare it, who has to review it, and what happens when a difference cannot be resolved by the deadline.

Written that way, the policy survives a system migration and a change of staff. It also does the thing a policy is really for, which is to make an omission visible. If the policy names every account in scope and assigns a frequency, then an account that was not reconciled last quarter is a documented exception rather than something nobody noticed.

What should a general ledger reconciliation policy include?

Eight elements. Anything less and the policy cannot be enforced or tested, which means it cannot be relied on by you or by an auditor.

How often should general ledger accounts be reconciled?

Frequency should follow risk, not convenience. Reconciling every account monthly sounds rigorous and in practice produces worse coverage than a tiered schedule, because the team runs out of time and the accounts that get skipped are chosen by whatever is hardest rather than by what matters least. A workable tiering looks like this.

Notice which accounts have an independent third-party source and which do not. That line divides two genuinely different controls. Where an external record exists, reconciliation is a comparison against evidence somebody else produced. Where it does not, as with prepaids and accruals, you are checking internal arithmetic against internal assumptions, and the policy should say plainly that the control is weaker and require a documented reviewer with the standing to challenge the assumption.

What are the general ledger account reconciliation steps?

The policy should require these steps in this order, because the order is what makes the result reviewable.

1. Fix the date and confirm the period is closed to posting. A reconciliation prepared while entries are still landing reconciles to a balance that no longer exists.
2. Pull the general ledger balance for the account, entity, and currency, as of that date.
3. Pull the independent source: the bank statement, the subledger aging, the processor settlement report, or the maintained schedule.
4. Compute the difference and note its direction, which immediately halves the list of possible causes.
5. Identify and explain every reconciling item individually, with an amount, a date, a cause, and the support. A total labeled "timing differences" is not a reconciling item, it is a gap.
6. Age the open items against the policy limit and escalate anything past it.
7. Correct what is wrong in the right place, which for a control account usually means the subledger rather than a journal to the control account itself.
8. Sign, date, and submit for review, retaining the support with the reconciliation rather than somewhere a reviewer would have to go looking for it.

Step five is where policies earn their keep and where most reconciliations quietly fail. The detailed mechanics of tying detail back to a control account are covered in our guide to subledger to general ledger reconciliation, and the broader process in general ledger reconciliation.

What counts as adequate support for a reconciliation?

Adequate support means a reviewer who was not present can reach the same conclusion without asking you a question. Concretely: the general ledger balance as reported by the system, the independent source document, an itemized list of every reconciling item with its cause, and the underlying documentation for each item, retrievable rather than merely referenced. A reconciling item described as "invoice from vendor" with no invoice attached is an assertion.

The retrieval requirement is the part policies usually get wrong. Support that exists but takes twenty minutes to locate fails the control in the only situation that matters, which is when somebody is testing a sample of twelve items under time pressure. For expense-backed and card accounts, where the support is frequently a photograph of a receipt sitting in someone's phone, that means getting the amounts and dates off those images into a searchable list as part of the monthly routine rather than the week the auditors arrive. The policy should state the retrieval standard explicitly: support must be attached to the reconciliation, in the retention system, at the time of sign-off.

Who prepares and who reviews the reconciliation?

The preparer should not be the person who has authority to post entries to the account being reconciled, wherever headcount allows. In a team where it does not allow, the policy should say so honestly and name the compensating control, which is normally a documented review by someone outside the accounting function, most often the owner or a board member, on the high-risk accounts only. A policy that quietly requires segregation the organization cannot deliver is worse than one that acknowledges the limitation and compensates for it, because the first produces false comfort and a signed form.

The reviewer needs a defined checklist, otherwise review collapses into checking that the difference is zero. At minimum the reviewer confirms the source document is genuinely independent and matches the date, every reconciling item has a cause and support, no item has aged past the policy limit, and any correction was posted in the right place. Recording who reviewed what and when is the evidence an auditor actually tests, which is why an audit trail of the review matters as much as the reconciliation itself.

What is general ledger account analysis and reconciliation?

Account analysis is the step beyond reconciliation. Reconciliation asks whether the balance agrees with its support. Analysis asks whether the balance makes sense: is it moving the way the business is moving, does the composition look right, has an item been sitting there for three quarters, is the account being used for something it was never intended for. The two are usually named together in job descriptions and policies because reconciling without analyzing catches errors but misses drift.

A practical way to require this in policy is to mandate a short written commentary on high-tier accounts each period: what changed, why, and what is unusual. It costs a few sentences per account and it is where the genuinely interesting findings come from, because a reconciliation that ties perfectly can still be hiding a suspense account that has quietly become a parking lot.

What is fund GL reconciliation?

In governmental and nonprofit accounting, activity is tracked by fund, each with its own restrictions on how money may be used, and the general ledger has to reconcile both in total and by fund. That second requirement is the whole difference. A cash account can tie out perfectly in aggregate while individual fund balances are wrong, which in a restricted-fund environment is not a bookkeeping error but a compliance problem, since it can mean restricted money was spent on unrestricted purposes.

A policy in that setting has to add two things: reconciliation by fund as well as in total, and an explicit check that interfund transfers were authorized and recorded on both sides. Interfund balances should net to zero across the entity, and the policy should require that check by name, because it is the one that catches a transfer posted once.

Where reconciliation policies fail in practice

Four failures account for most of it. First, scope drift: a new bank account or processor is opened and never added to the reconciliation list, so it goes unreconciled for a year without anybody being at fault. The fix is a policy requirement that opening any new account or connecting any new payment source triggers an update to the schedule.

Second, the aging limit that does not exist. Without one, an unexplained item becomes permanent through inertia, carried forward each month because it was there last month. Third, review without a checklist, which produces a signature and no test. Fourth, and most common, a policy that describes a control the team does not have the capacity to perform, at which point the practice diverges from the document and the document becomes the liability, since an auditor now has your own written standard to measure you against.

How reconciliation software fits into the policy

Software can perform the mechanical parts of the control and produce the evidence, and it cannot own the policy. Being precise about the split is worth doing, because it is also the honest answer to what a tool like ours does. Reconciler matches transaction-backed accounts (cash, corporate cards, clearing and suspense, undeposited funds, processor receivables) against your bank feeds, cards, Stripe, PayPal, Square, and your QuickBooks, Xero, NetSuite, Sage Intacct or Business Central ledger, read-only. It produces the itemized reconciling items with a plain-English reason for each match, ranks what did not tie, and records who reviewed what and when. That is the evidence standard and the audit trail your policy requires, generated as a by-product rather than assembled at close.

What it does not do: it does not build rollforward schedules for prepaids, accruals, or fixed assets, it does not run certification workflow, and it does not post journal entries. The tiering decisions, the escalation thresholds, the review, and the sign-off remain the finance team's, which is where accountability belongs. If the accounts consuming your close are the transaction-backed ones, balance sheet reconciliation software covers how the substantiation works and transaction matching software covers the engine underneath it. If the accounts that never reconcile are the processor ones, that is a specific and harder problem addressed in payment reconciliation software. Controllers writing the policy in the first place usually want account reconciliation for controllers.

A minimum viable policy

If you have nothing today, a single page beats a project. Name the accounts in scope and assign each to a high, medium, or low tier. State the frequency and a deadline in business days after period end for each tier. Name the preparer and reviewer roles, and say what the reviewer checks. Set an unexplained-difference escalation threshold in dollars and an aging limit in days for open items. State that support must be attached at sign-off and retained for seven years. Then, and this is the part that decides whether any of it holds, put a date on it and a review cycle, so it gets revisited when your account list changes rather than inherited unread by whoever has the job next.