Balance Sheet Reconciliations in Practice
2026-10-05
Notes on the close
A balance sheet reconciliation demonstrates that a general ledger balance agrees with an independent source of support, and that every difference between the two has been identified, assigned an owner, and cleared. This guide covers Sections 6.1 to 6.10 of a Record-to-Report handbook: the shared methodology first, then each major account type, with the usual causes of differences, worked examples, the journal entries that resolve them, and the workflow an analyst follows. All figures are illustrative.

Section 6.1
Reconciliation Methodology
Every reconciliation, whatever the account, follows the same five steps. The handbook pairs each step with the evidence an auditor expects to see.
| Step | Question | What the analyst does | Evidence |
|---|---|---|---|
| 1. Agree | Does the GL equal the supporting source? | Place the two balances side by side and calculate the total difference | GL extract plus subledger, bank statement or other source |
| 2. Explain | What are the reconciling items? | Break the difference into named items, each with an amount | Reconciliation schedule |
| 3. Age | How old is each item? | Record the date each item arose and calculate its age | Aging column or tracker |
| 4. Resolve | Who owns each item, and by when will it clear? | Assign an owner and target date; correct, reclassify, or allow timing items to clear | Action log |
| 5. Certify | Has an independent review taken place? | A reviewer other than the preparer signs off | Sign-off with reviewer timestamp |
How the steps depend on one another
Explain must come before Age. A total difference of ₹20,000 has no date of its own; only individual items do. An outstanding cheque of ₹15,000 may be three days old while a bank charge of ₹5,000 arose on another date, and the two cannot be averaged into a meaningful age. Age cannot be calculated until the difference has been broken into named items.
Agree is not a prerequisite for Explain, but it controls completeness. An analyst may already know from the cheque register that ₹15,000 of cheques are outstanding before any balances are compared. When the comparison then shows a ₹20,000 difference, the ₹5,000 residual shows that at least one item is still unidentified and prompts the search for it. Agree therefore confirms when Explain is finished.
Which accounts to reconcile, and how often
Not every GL account needs a monthly reconciliation. Companies scope by risk.
| Account type | Typical frequency | Reason |
|---|---|---|
| Cash and bank | Monthly | High transaction volume; direct fraud exposure |
| Accounts receivable | Monthly | High volume; judgement in provisioning |
| Accounts payable | Monthly | High volume; external vendor-statement exposure |
| Fixed assets | Monthly or quarterly | Lower volume, high value per item |
| Inventory | Monthly (book); periodic (physical count) | Shrinkage and costing risk |
| Payroll | Monthly | Statutory deduction accuracy; accrual timing |
| Intercompany | Monthly | Two independently maintained books |
| Suspense and clearing | Monthly, mandatory | Skipping it allows errors to stay hidden |
| Share capital and dormant accounts | Quarterly or annually | Low activity, low risk |
Materiality threshold
Not every difference is investigated individually. The company sets a threshold, either a fixed amount (for example ₹10,000) or a percentage of the account balance (for example 0.5%), below which items may be cleared in aggregate as immaterial. Without a threshold, analysts spend their time chasing differences of a few rupees.
The standard template
Whether kept in Excel (smaller companies) or in dedicated reconciliation software (larger ones), the layout is largely fixed: GL balance, supporting-schedule balance (subledger, bank statement, register or count), variance, a list of reconciling items each with amount, age, owner and target date, preparer signature and date, and independent reviewer signature and date.
When the review fails
If the reviewer finds an unexplained item or missing evidence, the reconciliation returns to the preparer and is not signed off until the point is resolved. Because this loop can delay the close, mature teams start reconciliations early in the close calendar rather than on the final day.
Common mistakes auditors look for
- Plugging. Adding a reconciling item such as "miscellaneous adjustment ₹3,200" with no identified cause, purely to make the figures agree. This hides the underlying error and is a major audit red flag.
- Self-certification. The preparer signs as reviewer, or the reviewer sits in the same team and is not independent.
- Stale reconciliations. The reconciliation exists, but sign-off has been pending for months, so no review has actually taken place.
Section 6.2
Bank Reconciliation
The bank statement is an external, independently produced record. In a bank reconciliation the books are adjusted to the bank, with one exception: where the bank itself has made an error, the company raises a dispute and the bank corrects it.
Typical reconciling items
| Item | Where it sits | Entry required |
|---|---|---|
| Outstanding (unpresented) cheques | Books ahead of bank | None; clears when presented. Age and monitor |
| Deposits in transit | Books ahead of bank | None; should be credited within one or two working days, otherwise investigate |
| Bank charges | Bank ahead of books | Dr Bank charges expense; Cr Bank |
| Standing instruction or auto-debit (EMI, premium) | Bank ahead of books | Dr Expense or liability; Cr Bank |
| Interest credited | Bank ahead of books | Dr Bank; Cr Interest income |
| Dishonoured cheque | Bank ahead of books | Dr Accounts receivable (customer); Cr Bank |
| Direct credit (RTGS, NEFT, UPI) without invoice reference | Bank ahead of books | Dr Bank; Cr Accounts receivable once identified, otherwise Cr Unapplied cash or suspense |
| Bank error | Bank only | No entry in the books; dispute with the bank |
Worked example: bank balance to cash book balance
At 31 March the bank statement shows ₹12,68,000 and the cash book shows ₹12,45,000.
| Item | Amount (₹) | Effect |
|---|---|---|
| Balance as per bank statement | 12,68,000 | |
| Cheques issued, not yet presented (3 cheques) | 35,000 | Deduct |
| Cheque deposited, not yet credited by the bank | 18,000 | Add |
| Bank charges debited by the bank, not yet in the books | 1,000 | Add |
| Insurance premium auto-debited, not yet in the books | 8,500 | Add |
| Interest credited by the bank, not yet in the books | 2,500 | Deduct |
| Customer cheque dishonoured and reversed by the bank, not yet in the books | 12,000 | Add |
| Customer RTGS credited directly by the bank, not yet in the books | 25,000 | Deduct |
| Balance as per cash book | 12,45,000 |
The same items, worked in the opposite direction, run from the cash book balance of ₹12,45,000 back up to the bank statement balance of ₹12,68,000, with every add and deduct reversed.
Rule for the signs. Starting from the bank balance, apply the effect of items the books have recorded and the bank has not (outstanding cheques are deducted; deposits in transit are added), and reverse the effect of items the bank has recorded and the books have not (charges, auto-debits and dishonoured cheques are added back; interest and direct credits are deducted). Working from the cash book to the bank applies the mirror image.
Adjusting entries
Only items that the books have not yet recorded need entries.
| Item | Debit | Credit | Amount (₹) |
|---|---|---|---|
| Bank charges | Bank charges expense | Bank | 1,000 |
| Insurance auto-debit | Insurance expense (or prepaid insurance) | Bank | 8,500 |
| Interest credited | Bank | Interest income | 2,500 |
| Dishonoured cheque | Accounts receivable (customer) | Bank | 12,000 |
| Direct RTGS credit | Bank | Accounts receivable (or unapplied cash if not yet identified) | 25,000 |
After these entries the cash book balance is ₹12,45,000 − 1,000 − 8,500 + 2,500 − 12,000 + 25,000 = ₹12,51,000. The bank side, adjusted for the outstanding cheques and the deposit in transit, is ₹12,68,000 − 35,000 + 18,000 = ₹12,51,000. Both sides now agree. The two remaining reconciling items are timing differences that clear on their own.
Stale and post-dated cheques
Stale cheques. In India a cheque is valid for three months from its date. An outstanding cheque that passes this limit can no longer be encashed. The original payment entry is reversed (debit Bank, credit the vendor or payable account), which restores the liability, and a fresh payment is made. The age of the outstanding-cheque list should be reviewed in every cycle; cheques left outstanding for six months or a year are a common audit finding.
Post-dated cheques. A cheque received with a future date is not a receipt until that date. Track it in a memo register of post-dated cheques in hand and post it to the ledger on its date; recording it earlier overstates cash.
Operating considerations
- Statement source. Larger companies receive bank statements electronically every day (MT940 or camt.053 files over a host-to-host link or SWIFT). Smaller companies often download and upload statements manually each month.
- Auto-matching. In mature setups the system commonly clears 70-90% of statement lines automatically. The remainder needs manual review, which is where analyst time is spent.
- Segregation of duties. A person who initiates or approves payments should not prepare the bank reconciliation, otherwise an improper payment could be concealed in their own reconciliation.
- Overdraft and cash credit accounts. The mechanics are identical; the bank balance is a liability, so the signs reverse.
- Multiple accounts and sweeps. Each account is reconciled separately. A master-account reconciliation is not enough, because timing differences arise at individual account level.
How the MT940 feed works
MT940 is the SWIFT standard format for an electronic bank statement. Its structure explains why automated bank reconciliation works and where it stops.
| Tag | Meaning |
|---|---|
| :20: | Transaction reference number (identifies the file) |
| :25: | Account identification |
| :28C: | Statement and sequence number |
| :60F: | Opening balance (first) |
| :61: | Statement line, one per transaction: value date, debit or credit mark, amount, transaction type and references. Repeats for every transaction |
| :86: | Information to the account owner: the narrative attached to the preceding :61: line |
| :62F: | Closing balance (final) |
The format carries a built-in integrity check: the opening balance plus the net of all statement lines must equal the closing balance. A file that fails this check is incomplete or corrupt and should be rejected or flagged at parsing.
Bank core system
→ MT940 file assembled (tag-based SWIFT format)
→ Delivered to the company (SWIFT FileAct, host-to-host, SFTP or portal download)
→ ERP or treasury system parses each statement line (:61: and :86:)
→ Auto-match engine (reference, amount, date)
→ Matched: cleared automatically against open items in the cash book or GL
→ Unmatched: routed to the exception queue
→ Analyst investigates and books the missing entry
→ Tie-out: opening balance + statement lines = closing balance, agreed to the GL
How an auto-match engine typically ranks candidates. Matching rules are usually configured in tiers, from most to least certain. The exact weights differ between ERP and treasury tools, but the common pattern is a unique reference with an exact amount (for example a UTR or invoice number in the :86: narrative), cleared automatically; amount plus counterparty within a date window where only one open item qualifies, also cleared automatically; grouped matches, where one bank line settles several open items or several lines settle one item, which usually needs specific rule configuration and often goes to review; and tolerance matches, where the amount differs slightly (for example a bank charge netted from a receipt) or the date falls just outside the window, normally flagged for review rather than cleared.
When more than one open item qualifies at the same tier, a well-configured engine does not guess; it leaves the line in the exception queue. The unmatched share is typically the same set of items listed in the reconciling-items table above (bank charges, standing instructions, dishonoured cheques, direct credits): the bank has recorded them, but the books have no corresponding entry to match against.
Workflow
| Step | Action |
|---|---|
| 1 | Obtain the bank statement and compare its closing balance with the cash book balance |
| 2 | List unmatched items on both sides (cheque register and cash book against the statement) |
| 3 | Classify each item as a timing item (clears by itself) or an error or unrecorded item (needs action) |
| 4 | Post adjusting entries for unrecorded items; dispute bank errors with the bank |
| 5 | In the next cycle, confirm that timing items cleared; investigate any cheque outstanding beyond three months |
| 6 | Independent reviewer signs off |
Section 6.3
Accounts Receivable Reconciliation
This reconciliation compares the AR aging (the sum of open invoices by customer, taken from the subledger) with the GL accounts receivable control account.
Why differences arise when the subledger is integrated
When a transaction is entered through the AR module, the system posts to the customer subledger and to the GL control account in a single step, so the two agree by design. Differences arise only where a transaction reaches one side and not the other: a journal posted directly to the control account in the GL, bypassing the AR module; a subledger transaction whose GL posting has failed or is held in a batch; postings dated in different periods on each side; foreign-currency revaluation posted at control-account level; or migration or opening-balance differences.
The probability for any single transaction is low, but volume turns a small percentage into a few items every month. Some situations, such as a legal settlement or the merging of customer accounts after an acquisition, have no standard AR transaction type and can only be posted through the GL. This is why the reconciliation is monthly and why manual journals to control accounts are the first thing checked.
Worked example
| AR subledger total (aging report) | ₹18,45,000 |
| GL AR control account | ₹18,20,000 |
| Variance | ₹25,000 |
In each case below the GL is lower than the subledger.
| Cause | Amount (₹) | What happened |
|---|---|---|
| Manual write-off journal | 10,000 | A small, old customer balance was written off directly in the GL; the subledger still shows it open |
| Manual credit journal | 5,000 | A customer rebate was posted to the control account in the GL only |
| GL posting held | 8,000 | Invoices exist in the subledger, but their GL posting is stuck in a failed batch |
| FX revaluation | 2,000 | Period-end revaluation loss on foreign-currency receivables posted at control-account level (system-dependent) |
| Total | 25,000 |
Aging-quality issues
Two common AR problems do not necessarily create a difference between subledger and GL, but they distort the aging and should be cleaned in the same cycle.
Unapplied cash. A customer pays, but the payment cannot be matched to specific invoices: the remittance advice is missing, one payment covers several invoices without a breakdown, or the customer sent a round figure. Until it is matched, the receipt sits as an unapplied credit, so open invoices look overdue while the cash is already in the bank. Unapplied cash is also a tracked collections KPI, because an accumulating balance understates real collections performance.
Misapplied credit notes. A credit note applied to the wrong invoice, or left unapplied, leaves the customer's total correct but misstates the aging by invoice.
Why AR has no routine counterparty check
Accounts payable benefits from a second, external check because vendors send statements to protect their own interest in being paid. Customers have no equivalent incentive: if a customer is under-billed, nothing prompts them to say so. AR reconciliation therefore depends mainly on internal control over billing accuracy. The main outside checks are the auditors' year-end debtor confirmations and customer disputes.
Workflow
| Step | Action |
|---|---|
| 1 | Run the customer-wise aging and take the total |
| 2 | Compare it with the GL AR control account |
| 3 | If they differ, review the period's manual journals posted directly to the control account |
| 4 | Check FX revaluation entries where foreign-currency customers exist |
| 5 | Check for GL postings held or failed from the subledger (interface and batch logs) |
| 6 | Separately review unapplied cash and credit notes for aging accuracy |
| 7 | Escalate to the interface or IT team if differences remain unexplained |
The order is deliberate: manual journals are the most common cause and the easiest to find, while interface failures are the least common and the most time-consuming to investigate.
Section 6.4
Accounts Payable Reconciliation
AP reconciliation works at two levels. Level 1 is internal: the AP subledger against the GL AP control account. Level 2 is external: the company's open items against the vendor's own statement. Level 2 is the structural difference from AR.
Level 1: subledger to GL
The integrated-posting logic is the same as for AR: an invoice or payment entered through the AP module updates the vendor ledger and the control account together.
| AP subledger total (vendor-wise open items) | ₹22,10,000 |
| GL AP control account | ₹21,85,000 |
| Variance | ₹25,000 |
In each case below the GL is lower than the subledger.
| Cause | Amount (₹) | What happened |
|---|---|---|
| Manual debit journal to the control account | 12,000 | A vendor rebate or write-back was posted directly in the GL; the vendor ledger is unchanged |
| Payment posted to GL but invoice not cleared | 8,000 | A payment was recorded in the GL (for example through a manual bank payment journal) while the invoice stays open in the subledger |
| GL posting held | 5,000 | Invoices are recorded in the subledger, but the GL posting was held or rejected because of an interface or period issue |
| Total | 25,000 |
GRNI/GRIR is a separate clearing account and is reconciled and aged on its own (see 6.10). A GRNI balance that was cleared incorrectly does not appear as an AP subledger-to-GL difference, but it misstates accruals, expense and inventory.
Level 2: company records to vendor statement
Vendors send statements because they want to be paid in full, so this check runs largely on the vendor's initiative.
| AP per the company's books, Vendor X | ₹5,00,000 |
| Balance per Vendor X's statement | ₹5,50,000 |
| Difference | ₹50,000 |
| Cause | Amount (₹) | Which side is ahead |
|---|---|---|
| Invoice sent by the vendor, not yet received or booked by the company (courier or email delay) | 30,000 | Vendor is ahead. The company must book the invoice |
| Payment made by the company, not yet applied by the vendor | 20,000 | Company is ahead. This is timing and clears when the vendor applies the payment |
| Total | 50,000 |
The handbook classifies differences as missing invoice, payment in transit, credit, dispute or timing, with an owner and target date for each. A duplicate payment is usually spotted by the vendor first, because the extra cash arrives in their account.
Statement reconciliation is applied by materiality: companies typically request statements from their high-value vendors (for example the top 20 to 30 out of a few hundred), not from every supplier.
Level 1 compares the company's subledger with its own GL. Level 2 compares the same subledger with the vendor's records. Both are matching exercises at invoice level, but the other side of the comparison changes.
Workflow
| Step | Action |
|---|---|
| 1 | Take the AP subledger total from the aging report and compare it with the GL AP control account |
| 2 | Review manual journals posted directly to the AP control account |
| 3 | Check for payments posted to the GL but not cleared against invoices, and for held or failed GL postings |
| 4 | Review GRNI aging separately for balances older than 90 days |
| 5 | Once Level 1 agrees, request statements from high-value vendors |
| 6 | Match the vendor's open items to the company's open items line by line |
| 7 | Classify differences (missing invoice, payment in transit, credit, dispute, timing), assign owners and target dates |
| 8 | Close resolved items and retain supplier correspondence as evidence |
Section 6.5
Fixed Asset Reconciliation
The fixed asset register holds one record per asset (tag, location, custodian, depreciation schedule). The GL holds aggregate accounts: gross cost, and accumulated depreciation as a contra account. Net book value (NBV) is simply cost less accumulated depreciation. It is a computed figure, not a ledger account, and gross cost stays at original cost until the asset is removed. For that reason the register is reconciled to the GL on cost and accumulated depreciation separately, not on NBV alone.
Why the net figure is not enough
| Register (₹) | GL (₹) | Variance (₹) | |
|---|---|---|---|
| Gross cost | 85,00,000 | 86,20,000 | 1,20,000 |
| Accumulated depreciation | 32,50,000 | 33,70,000 | 1,20,000 |
| Net book value | 52,50,000 | 52,50,000 | 0 |
A reconciliation closed on NBV would show nothing wrong, yet a ₹1,20,000 problem sits in each component and happens to offset.
The cause here: an asset costing ₹1,20,000 had been fully depreciated (accumulated depreciation also ₹1,20,000, NBV zero). It was disposed of and removed from the register, but the disposal journal was never posted in the GL. Both GL accounts therefore stayed at their old values, and because the asset's NBV was already zero, the net figure showed no difference. Disposals of fully depreciated assets are the easiest to miss for exactly this reason, which is why they are checked separately.
Other common causes
| Cause | Account affected |
|---|---|
| Disposal recorded in the register, journal missing in the GL | Gross cost and accumulated depreciation |
| Depreciation run partially posted (batch failure) | Accumulated depreciation |
| Capitalisation date differs between register and GL | Accumulated depreciation, because depreciation starts from that date |
| Transfer from capital work in progress timed differently | Gross cost |
| Impairment or write-down recorded on one side only | Carrying amount, usually through accumulated depreciation or an impairment account |
Journal entries from purchase to disposal
Assumptions: cost ₹1,00,000, useful life five years, no residual value, straight-line depreciation of ₹20,000 a year.
Entry 1: purchase and capitalisation (Year 0)
Dr Fixed asset (gross) ₹1,00,000
Cr Bank or vendor payable ₹1,00,000
Entries 2 to 6: depreciation (end of Years 1 to 5)
Dr Depreciation expense ₹20,000
Cr Accumulated depreciation ₹20,000
| Year-end | Accumulated depreciation (₹) | NBV (₹) |
|---|---|---|
| Year 1 | 20,000 | 80,000 |
| Year 2 | 40,000 | 60,000 |
| Year 3 | 60,000 | 40,000 |
| Year 4 | 80,000 | 20,000 |
| Year 5 | 1,00,000 | 0 |
Entry 7: disposal for scrap proceeds of ₹5,000
Dr Accumulated depreciation ₹1,00,000
Dr Bank ₹5,000
Cr Fixed asset (gross) ₹1,00,000
Cr Gain on disposal ₹5,000
Debits and credits both total ₹1,05,000. If the asset is scrapped for nothing, the entry is simply Dr Accumulated depreciation ₹1,00,000, Cr Fixed asset ₹1,00,000, with no effect on profit.
Why both accounts must be cleared even though NBV is zero. At the end of Year 5, the gross account still stands at ₹1,00,000 and accumulated depreciation also stands at ₹1,00,000. NBV of zero is the difference between them, not a balance in its own right. When the asset leaves the company, both balances must be removed, and the system does not do this on its own: the disposal entry has to be posted. On the balance sheet the two accounts normally appear on separate lines, with NBV shown as the net subtotal.
Over the asset's life the company recognised ₹1,00,000 of depreciation and a ₹5,000 gain, a net cost of ₹95,000: the market paid slightly more than the schedule assumed.
Workflow
| Step | Action |
|---|---|
| 1 | Extract total gross cost and total accumulated depreciation from the register, separately |
| 2 | Compare each with its GL account; do not rely on the net figure alone |
| 3 | For a cost difference, list the period's additions, disposals and CWIP transfers from the GL and match them with register movements |
| 4 | For an accumulated depreciation difference, check the depreciation batch log: was it fully posted, and were all assets covered? |
| 5 | Check disposals of fully depreciated assets separately, since the net check cannot detect them |
| 6 | Trace any residual difference to asset ID level |
Section 6.6
Inventory Reconciliation
Inventory differs from the other reconciliations in what it is compared against. The support is not another ledger; it is the physical count of stock in the warehouse. The count is treated as the authoritative figure, and the books are adjusted to it. Large variances are recounted before any adjustment is posted.
Worked example
SKU: steel rod, 10 mm. Standard cost ₹200 per unit.
| Quantity | Value (₹) | |
|---|---|---|
| Book (system) | 500 | 1,00,000 |
| Physical count | 485 | 97,000 |
| Variance | −15 units | −3,000 |
The variance has two causes, and they are treated very differently.
Shrinkage: 10 units, ₹2,000. Theft, damage or spoilage confirmed by a security review or damage report. This is a genuine economic loss.
Dr Inventory shrinkage expense ₹2,000
Cr Inventory ₹2,000
Unrecorded transfer: 5 units, ₹1,000. The stock was sent to the retail counter, but the transfer slip was never processed in the system. Nothing was lost; the stock is simply recorded in the wrong place.
Dr Inventory, retail counter ₹1,000
Cr Inventory, warehouse ₹1,000
Shrinkage reaches the P&L, while the transfer does not. Writing off every shortage as shrinkage would book more expense than the real loss, so each variance is traced to its root cause before the entry is chosen.
Errors the count cannot detect
If quantities agree (book 500, physical 500) the value can still be wrong. A receipt posted at the wrong unit cost (for example ₹220 keyed in where the batch cost ₹200) leaves quantity correct and valuation overstated. A count only counts units; it does not test rates. Costing errors are found by verifying unit costs against purchase records, as a separate exercise on sampled SKUs. Under standard costing the difference surfaces as a purchase price variance that then needs investigation; under actual costing (such as FIFO) it can stay embedded in inventory value until someone audits the cost layers.
Segregation of duties
Whoever performs the physical count must not approve the book adjustment. Warehouse staff count; the finance team reviews and approves the adjustment entries. Otherwise a shortage could be hidden, or a count falsified to cover an earlier mistake.
Workflow
| Step | Action |
|---|---|
| 1 | Conduct the physical count (cycle count or full count) |
| 2 | Compare the count with book quantity for each SKU |
| 3 | Flag variances above the materiality threshold; recount large ones |
| 4 | Trace each flagged item to its root cause: shrinkage, recording error or timing |
| 5 | Post a write-off for shrinkage and a correcting entry for unrecorded movements; do not treat them alike |
| 6 | Separately verify unit costs on sampled SKUs against purchase records |
| 7 | Have finance approve the adjustment entries, not the warehouse team |
Section 6.7
Payroll Reconciliation
Payroll reconciliation also works at two levels. Level 1 is internal: the payroll register against the GL. Level 2 is external: GL payables for statutory dues against what has actually been filed on the statutory portals (for example EPFO for provident fund, and the income-tax portal for TDS).
Level 1: payroll register to GL
| Payroll register, total cost to company (gross salary 20,00,000 plus employer PF 1,20,000) | ₹21,20,000 |
| GL salary and related expense | ₹21,45,000 |
| Variance | ₹25,000 |
| Cause | Amount (₹) | What happened |
|---|---|---|
| Post-payroll manual bonus | 15,000 | HR posted a late bonus directly in the GL; it is not in the payroll register |
| Separate weekly contract-staff payroll | 10,000 | A weekly pay cycle for contract staff posts to the same GL expense accounts but is not part of the monthly register |
Other common causes are further pay cycles (another entity or country), statutory deduction rates that differ between the payroll system and the GL posting, and post-payroll adjustments for bonus or tax corrections that reach the register but not the GL.
Level 2: statutory filings to GL payables
| PF payable per GL (employee and employer shares combined) | ₹2,40,000 |
| Amount in the filed EPFO return | ₹2,35,000 |
| Variance | ₹5,000 |
Cause: a mid-month joiner's PF was calculated for the full month in the GL postings, while the filed return used the correctly prorated amount. Statutory portals keep their own independent record and may levy interest or penalties on mismatches, so this check cannot be skipped.
The accrual reversal trap
If a month's payroll run completes after the close, the close needs an estimated accrual, which must then be reversed when the actual payroll is booked. Example: March payroll is processed in April; the March accrual is ₹19,50,000 and the actual payroll is ₹19,80,000.
| Entry | Debit (₹) | Credit (₹) |
|---|---|---|
| March close, accrual: Salary expense / Accrued salary payable | 19,50,000 | 19,50,000 |
| April, reversal: Accrued salary payable / Salary expense | 19,50,000 | 19,50,000 |
| April, actual payroll: Salary expense / Bank or salary payable | 19,80,000 | 19,80,000 |
Across the two months the expense totals ₹19,80,000: ₹19,50,000 in March and a net ₹30,000 in April. If the reversal is missed, both the accrual and the actual stay in the ledger and the expense totals ₹39,30,000, a double count. Because reversal is a separate step and not automatic, it is easy to miss.
The check is simple: the accrued salary payable account should be zero after the April close. If it is not, the reversal was missed. This is the highest-value single check in payroll reconciliation, because the impact is large and nothing flags it automatically.
Segregation of duties
The HR or payroll team that produces the register must not sign off the GL reconciliation. Finance verifies independently, because payroll data is both sensitive and error-prone.
Workflow
| Step | Action |
|---|---|
| 1 | Take register totals (gross pay, deductions, employer contributions) |
| 2 | Compare with GL salary expense (Level 1) |
| 3 | Check the accrued salary payable account specifically: was last month's accrual reversed? |
| 4 | Verify statutory payable accounts (PF, ESI, TDS) separately, since each has its own filing |
| 5 | Match GL balances with the filings on the statutory portals (Level 2) |
| 6 | List post-payroll manual adjustments and check any separate pay cycles |
Section 6.8
Tax Reconciliation
This section is intentionally brief. The handbook treats tax reconciliation as the same five-step method applied to tax accounts, and places the tax-specific controls in Section 12 (tax and statutory accounting interfaces), which has not yet been worked through in detail. Those controls are listed in the handbook as: reconcile tax subledgers to the GL; validate tax codes and rates against policy; track input and output taxes and withholding; separate book and tax adjustments; and maintain filing and payment evidence. A full treatment with worked examples will be added once Section 12 is covered.
Section 6.9
Intercompany Reconciliation
Unlike AR and AP, intercompany has no external statement to compare against; both sides belong to the same group. The practical substitute is a confirmation of balances between the two entities, and matching is done pair by pair (for example India and US, India and Singapore, US and Singapore). The handbook's control point is that amounts match, or differences are explicitly explained. The reconciliation is performed in the transaction currency first, so that exchange-rate effects do not mix with real mismatches.
Worked example: one pair, in USD
| India's intercompany receivable (ICAR) from the US | $60,000 |
| US intercompany payable (ICAP) to India | $52,000 |
| Variance | $8,000 |
| Cause | Amount (US$) | What happened |
|---|---|---|
| Invoice in transit | 5,000 | India raised the invoice on 29 March; the US booked it on 3 April (the service was performed in March) |
| Cash in transit | 2,000 | The US wired payment on 28 March; it reached India's bank on 2 April |
| Amount-keying error | 1,000 | India's invoice was $10,000; the US booked $9,000 |
| Total | 8,000 |
Resolution entries
| # | Entity | Debit | Credit | Amount (US$) | Reason |
|---|---|---|---|---|---|
| 1 | US (March) | Service expense | ICAP, India | 5,000 | The service belongs to March, so the US accrues it in March |
| 2 | US | Service expense | ICAP, India | 1,000 | Correction to the invoice amount |
| 3 | Group (consolidation) | Cash in transit | ICAR, US | 2,000 | The wire is in transit; adjusted at group level |
After entries 1 and 2, India's ICAR is $60,000 and the US ICAP is $58,000. The remaining $2,000 is fully explained as cash in transit and is adjusted at group level (entry 3) so the balances eliminate. Where the amounts differ because of a keying error, the correct figure is set by the underlying invoice, not by negotiation between the entities.
The foreign-currency layer
FX arises only in the entity whose functional currency differs from the transaction currency. India's functional currency is the rupee, so its $60,000 receivable is a foreign-currency balance. Suppose it was booked at ₹82.50 (₹49,50,000) and the closing rate is ₹83.50 (₹50,10,000).
Dr ICAR, US (rupee carrying value) ₹60,000
Cr FX gain ₹60,000
The US entity's functional currency is the dollar, so its dollar payable creates no FX.
Worked example: three-entity matrix
| Pair | A's ICAR | B's ICAP | Difference |
|---|---|---|---|
| India and US | $60,000 | $52,000 | +$8,000 (explained above) |
| India and Singapore | $15,000 | $15,500 | −$500 |
| US and Singapore | $9,500 | $9,000 | +$500 |
When two pairs show equal and opposite differences (−$500 and +$500), check for a wrong counterparty first. Here the US invoiced Singapore $500, but Singapore booked it against India by mistake. Singapore corrects it:
Dr ICAP, India ₹500
Cr ICAP, US ₹500
Other practical causes
- A transfer-pricing true-up booked by one side and not the other (common at year-end).
- Different exchange-rate sources: one entity uses the bank rate, the other the group treasury rate (visible in the local-currency view).
- A credit note processed by one entity and not the other.
Controls
Group policy varies, but common practice is to set the intercompany cut-off one or two days before the normal close so that fewer items are in transit, to require both entities' controllers to confirm balances (not just one side), and to ensure the person who posts intercompany invoices does not sign off the reconciliation.
Link to elimination
An unreconciled difference does not eliminate. After elimination, the intercompany balance should be zero; whatever remains appears on the group balance sheet as an intercompany difference that must be explained to the auditors.
Workflow
| Step | Action |
|---|---|
| 1 | Set the intercompany cut-off date; all entities book their intercompany invoices and credit notes up to it |
| 2 | Each entity extracts its counterparty-wise intercompany balances in the transaction currency |
| 3 | Build the pair-wise matrix of ICAR against ICAP and calculate the differences |
| 4 | Classify each difference: cut-off, cash in transit, amount error, wrong counterparty, transfer-pricing adjustment or FX |
| 5 | If two pairs show equal and opposite differences, check for a wrong counterparty first |
| 6 | The entity at fault posts a correction, based on the underlying invoice |
| 7 | Both controllers confirm; document in-transit items |
| 8 | Run the elimination; any remaining balance is an unreconciled difference |
Section 6.10
Suspense, Clearing and Aged Reconciling Items
Suspense and clearing accounts are temporary parking accounts. They hold entries whose correct account is not yet known, or whose other half has not yet arrived. Common examples: bank suspense (unidentified receipts and debits), interface-failure suspense, payroll clearing, card clearing, GRNI/GRIR, and leftover data-migration balances.
The rule: at period end these accounts should be zero, or supported by a fully itemised and aged schedule.
Worked example (31 March)
| # | Item | Dr/Cr in suspense | Amount (₹) | Date | Age (days) |
|---|---|---|---|---|---|
| 1 | Unidentified NEFT receipt, no remittance reference | Cr | 1,50,000 | 12 Mar | 19 |
| 2 | Unknown bank auto-debit | Dr | 45,000 | 28 Feb | 31 |
| 3 | Vendor invoice parked after an interface failure | Cr | 1,20,000 | 5 Jan | 85 |
| 4 | Salary overpayment returned by an ex-employee | Cr | 40,000 | 20 Mar | 11 |
| 5 | Old migration balance with no support | Dr | 30,000 | 15 Apr (previous year) | 350 |
Gross against net. The same trap seen in fixed assets applies here.
| Gross credits (items 1, 3, 4) | ₹3,10,000 |
| Gross debits (items 2, 5) | ₹75,000 |
| Net credit balance | ₹2,35,000 |
The net figure of ₹2,35,000 hides ₹3,85,000 of items awaiting resolution. Debit and credit items are therefore always listed separately.
Age buckets and escalation
Thresholds follow company policy and may differ.
| Bucket | Items | Amount (₹) | Action |
|---|---|---|---|
| 0-30 days | 1, 4 | 1,90,000 | Assign an owner; normal follow-up |
| 31-60 days | 2 | 45,000 | Escalate to the team lead |
| 61-90 days | 3 | 1,20,000 | Escalate to the controller |
| Over 90 days | 5 | 30,000 | Write-off proposal with documentation |
Resolution entries
| # | Debit | Credit | Amount (₹) | What was found |
|---|---|---|---|---|
| 1 | Suspense | AR, Customer X | 1,50,000 | The receipt belonged to Customer X |
| 2 | Insurance expense | Suspense | 45,000 | The auto-debit was an insurance premium |
| 3 | Suspense | AP, Vendor | 1,20,000 | Interface fixed; invoice reposted to the vendor ledger |
| 4 | Suspense | Salary expense (or employee recoverable, if one was booked) | 40,000 | Refund of the overpayment |
| 5 | Write-off expense | Suspense | 30,000 | Written off after senior approval |
Debits to suspense total ₹3,10,000 (items 1, 3, 4) and credits total ₹75,000 (items 2, 5), a net debit of ₹2,35,000 that exactly offsets the net credit balance, leaving the account at zero.
Writing off the 350-day item. Before writing off, document what was done to find support (old files, migration logs, questions to the previous team), then obtain independent senior approval. Quietly clearing such items is an audit red flag.
GRNI aging
GRNI is the most common clearing account.
| Bucket | Amount (₹) | Action |
|---|---|---|
| 0-30 days | 5,50,000 | Normal; awaiting the invoice |
| 31-60 days | 1,50,000 | Buyer or AP follows up with the vendor for the invoice |
| 61-90 days | 60,000 | Check whether the invoice was posted against the wrong PO or receipt line, or is in dispute |
| Over 90 days | 40,000 | Investigate: invoice posted elsewhere (clear it); goods returned but receipt not reversed (reverse it); or vendor will never bill (reverse the accrual with approval) |
| Total | 8,00,000 |
The same bucket logic applies to aged reconciling items in other reconciliations: unapplied cash, unmatched intercompany items, and old outstanding cheques (stale after three months). An aged item without an owner and target date prevents the reconciliation from being signed off.
Prevention
- Block manual postings to suspense accounts; typically only the system or interface should post to them.
- Require a description on every suspense entry (source and reference number).
- Track the trend: gross balance, number of items, and the percentage of items older than 60 days.
Segregation of duties
The person who posts to suspense must not alone clear or write off the same item. A write-off needs independent approval.
Workflow
| Step | Action |
|---|---|
| 1 | Take the GL balance of the suspense or clearing account, with debit and credit items separate |
| 2 | List every item: amount, date, source document, Dr or Cr |
| 3 | Build age buckets (0-30, 31-60, 61-90, over 90 days) |
| 4 | Identify the owner and root cause of each item |
| 5 | Resolve: reclassify to the correct account, or fix the interface and repost |
| 6 | Escalate unresolved items by age; propose write-off for those over 90 days |
| 7 | Independent reviewer signs off: closing balance zero, or fully supported by the aged schedule |
Reference
Quick Reference
| Reconciliation | Compared against | Most common cause of difference | First check |
|---|---|---|---|
| 6.2 Bank | Bank statement | Timing items and bank items not yet in the books | List unmatched items on both sides |
| 6.3 AR | AR aging to GL control account | Manual journals posted directly to the control account | Review manual journals |
| 6.4 AP | AP aging to GL; vendor statements | Manual journals; invoices missing from the company's books | Manual journals, then vendor statement matching |
| 6.5 Fixed assets | Register to GL, cost and accumulated depreciation separately | Disposal recorded in the register but not in the GL | Reconcile cost and depreciation separately |
| 6.6 Inventory | Physical count to book | Shrinkage and unrecorded transfers | Count against book, SKU by SKU |
| 6.7 Payroll | Register to GL; statutory filings to payables | Post-payroll adjustments and multiple pay cycles | Accrued salary payable account |
| 6.8 Tax | See Section 12 | Pending | Pending |
| 6.9 Intercompany | Counterparty balances, pair by pair | Cut-off and cash-in-transit differences | Pair matrix in transaction currency |
| 6.10 Suspense and clearing | Itemised, aged schedule | Interface failures and unidentified receipts | List debit and credit items separately |
Written by Souvik Banerjee, RTR Financial Analyst. If you'd like to see this thinking applied to a real company, try the DCF tool or get in touch.