# Bank Recon Format: A Step-by-Step How-To Guide Source: https://www.digiparser.com/blog/bank-recon-format [See all posts](/blog) Last updated on May 22, 2026 # Bank Recon Format: A Step-by-Step How-To Guide [![Pankaj Patidar](https://avatars.githubusercontent.com/u/17493609?v=4) Pankaj Patidar @thepantales ](https://x.com/thepantales) ![Bank Recon Format: A Step-by-Step How-To Guide](https://cdnimg.co/676959fc-fff3-440b-8860-da6e53d455e3/c16280ca-de0c-4b7d-8f67-db21306006ce/bank-recon-format-how-to-guide.jpg) Month-end closes often fail in the same place. Revenue is posted, payables are booked, the trial balance looks mostly clean, and then cash refuses to tie. Your general ledger says one thing. The bank statement says another. Someone starts scanning for errors, someone else questions the posting date, and the staff accountant wonders whether they broke the close. They probably didn't. This is exactly why a **bank recon format** exists. A good reconciliation format does more than force two balances to agree. It shows, line by line, why they didn't agree in the first place, which items are timing differences, which items need journal entries, and which items signal a deeper process problem. In operations-heavy businesses, that distinction matters. If treasury activity, lockbox deposits, manual checks, customer returns, and bank fees all hit on different timelines, cash can look wrong even when the underlying activity is legitimate. The practical job isn't to make the numbers match by force. It's to build a schedule that explains the gap cleanly, documents the support, and leaves the next reviewer with no mystery to solve. # Why Your Bank and Book Balances Never Match At month-end, bank and book balances rarely match. That is a normal result of how cash activity moves through real systems. The bank balance reflects what the bank has processed as of the statement date. The book balance reflects what your team recorded in the general ledger based on checks issued, deposits logged, merchant activity, bank notices, and journal entries. In a clean close, those two records are supposed to be different before reconciliation. The work is explaining the difference, not treating every gap as an error. Timing is the first reason. A deposit can hit your cash receipts log today and the bank tomorrow. A check can reduce the ledger when AP issues it, then sit outstanding for days or weeks before it clears. In operations-heavy environments, the gaps get wider because cash moves through lockboxes, remote deposits, credit card processors, payroll files, manual wires, and bank cutoffs that do not line up neatly. Unrecorded items are the second reason, and they usually matter more than staff expect. Banks post fees, interest, NSF items, ACH debits, and fraud blocks whether accounting has seen them yet or not. If the team waits for month-end to notice those entries, the reconciliation turns from a matching exercise into cleanup. A simple test helps. Ask one question for each difference: did we record it first, or did the bank? If the company recorded it first, the item is often a timing difference on the bank side. If the bank recorded it first, accounting usually needs to book an entry. That distinction saves time and prevents bad fixes, especially when someone is tempted to force a plug into cash. Cash also behaves differently from other account reconciliations because it changes daily and gets touched by multiple teams. Treasury, AP, AR, payroll, and operations can all create reconciling items without realizing it. Teams building close checklists across several balance sheet accounts will see the same control logic in these [account reconciliation examples for different close scenarios](https://www.digiparser.com/blog/8-key-account-reconciliation-examples), but cash exposes process breaks faster than almost any other account. The practical goal is an adjusted cash balance you can support, review, and carry forward without questions. If the reconciliation explains each difference clearly, the mismatch did its job. It showed timing, identified missing entries, and exposed any process issue that needs attention before the next close. # Anatomy of a Standard Bank Recon Format The standard bank recon format is a **two-sided adjustment schedule**. One side starts with the ending balance per bank statement. The other starts with the ending balance per books. You adjust each side separately until both arrive at the same final cash number. Ramp lays out the core rule clearly: the adjusted bank balance and adjusted book balance must match exactly or the reconciliation isn't complete ([Ramp's explanation of bank reconciliation](https://ramp.com/blog/what-is-bank-reconciliation)). ![bank-recon-format-reconciliation-process.jpg](https://cdnimg.co/676959fc-fff3-440b-8860-da6e53d455e3/ae9d8114-87b5-42d3-a0f8-991e09064c7a/bank-recon-format-reconciliation-process.jpg) ## The two sides do different jobs The **bank side** handles items already in your books that the bank hasn't processed yet. The classic examples are deposits in transit and outstanding checks. The **book side** handles items already processed by the bank that your ledger hasn't recorded yet. That's where bank fees, interest, NSF checks, and bank memoranda usually sit until you post the necessary entry. That distinction is where new staff often get tripped up. They understand the math but miss the logic. If the company already recorded the item, it usually stays on the bank side as a timing item. If the bank recorded the item first, it usually belongs on the book side and often requires a journal entry. ## A usable format in Excel Below is a clean model. Keep it simple enough to review quickly, but detailed enough that every reconciling item can be traced. Bank Side Book Side Ending balance per bank statement Ending balance per books Add deposits in transit Add interest income not yet recorded Less outstanding checks Less bank fees not yet recorded Add or less bank error corrections, if any Less NSF or returned checks not yet recorded Adjusted bank balance Add or less other bank-originated items and book error corrections Adjusted book balance ## What each line is really telling you * **Ending balance per bank statement**. This is your external starting point for the period. * **Ending balance per books**. This is the general ledger cash balance before recon entries. * **Deposits in transit**. Receipts your team recorded, but the bank hasn't posted by statement date. * **Outstanding checks**. Checks issued and recorded internally, but not yet cleared the bank. * **Bank fees**. Charges the bank posted that your books haven't captured yet. * **Interest income**. Credits applied by the bank that need to be recorded in the ledger. * **NSF checks or returned items**. Deposits reversed by the bank that require a correction on the book side. > **Practical rule:** If an item can't be tied to support, it doesn't belong as a vague reconciling item. It belongs in investigation. A strong format also includes operational fields that teams skip too often: reconciliation date, period covered, preparer, reviewer, opening tie to the prior month, and support references for each unmatched item. Without those, the schedule may balance, but it still won't hold up under review. # Building Your Reconciliation Step-by-Step The mechanics of bank reconciliation aren't hard. The hard part is doing them in the right order and not skipping the evidence trail. Numeric describes the standard workflow as starting with the bank balance, adjusting for items like deposits in transit and outstanding checks, and separately adjusting the book balance for items like bank fees or interest until both adjusted balances match, creating a clear audit trail ([Numeric's bank reconciliation template guide](https://www.numeric.io/template/bank-reconciliation-template)). Start with the documents, not the spreadsheet. Pull the bank statement for the exact period, the cash general ledger detail, the prior month reconciliation, and any support for manual checks, deposits, and treasury activity. If your statement arrives as a PDF, converting it into structured rows before matching can make the process much faster. This walkthrough on [converting a bank statement to Excel](https://www.digiparser.com/blog/convert-bank-statement-to-excel) is useful when the source file isn't easy to work with directly. ![bank-recon-format-bank-reconciliation-process.jpg](https://cdnimg.co/676959fc-fff3-440b-8860-da6e53d455e3/e40ccd5c-89f0-434a-a5a3-1cbe0d214966/bank-recon-format-bank-reconciliation-process.jpg) ## Start with the prior month before touching current activity If the opening balance doesn't tie to the previous reconciliation, stop there. Don't build a new recon on top of an unresolved old one. That's how one small break turns into a rolling problem. Then match current-period items line by line. Tick deposits, withdrawals, ACH activity, and checks that appear in both the bank statement and the ledger. What remains unmatched becomes your working list. ## Build the schedule from the unmatched list Use this order: 1. **List bank-side timing items** such as deposits in transit and outstanding checks. 2. **List book-side items** that came from the bank and haven't been posted internally. 3. **Check whether any unmatched item is an error** in date, amount, or account coding. 4. **Calculate adjusted bank and adjusted book balances**. 5. **Post needed journal entries** for book-side items. 6. **Re-run the reconciliation** to confirm both sides match. Here's the practical split that keeps staff out of trouble: * **No journal entry needed** for deposits in transit and outstanding checks, because the books already reflect them. * **Journal entry usually needed** for bank fees, interest, NSF items, direct debits, or bank-originated credits and debits not yet in the ledger. A short training video can help if you're teaching this to a new team member or documenting the process for handoff: ## What works in a messy environment Operations-heavy teams need a repeatable rhythm more than a pretty worksheet. What works is: * **Daily tracking of manual checks** so they don't become mystery outstanding items at month-end * **A deposit log tied to cutoff** so late-day receipts aren't debated after the statement arrives * **A named owner for bank-originated transactions** such as fees, sweeps, and returns * **A reviewer who challenges stale items** instead of rolling them forward automatically What doesn't work is waiting for the bank statement, dumping transactions into Excel, and trying to "figure it out" from scratch each month. That process always takes longer than teams expect, and it hides recurring upstream issues. # Handling Common Reconciling Items and Adjustments A reconciliation starts to go sideways when staff treat every difference the same. They are not the same. Some items are pure timing. Others mean the ledger is missing activity and needs an entry before the month can close. The practical question is always the same. Did the books already capture the cash movement, or did the bank statement reveal something the ERP has not recorded yet? That distinction keeps the recon clean and keeps teams from posting entries they do not need. ![bank-recon-format-bank-statement.jpg](https://cdnimg.co/676959fc-fff3-440b-8860-da6e53d455e3/01bcb308-e427-41b4-9913-652fd9499aa3/bank-recon-format-bank-statement.jpg) ## Timing items on the bank side Deposits in transit and outstanding checks belong on the bank side because the books already reflect them. The bank is behind the company's cutoff. * **Deposits in transit**. Cash receipts were entered before month-end, but the bank posted them after statement cutoff. These should clear quickly in the next statement. If they do not, check the deposit detail, not just the total. In operations-heavy environments, a batched deposit can be short, duplicated, or posted to the wrong date. * **Outstanding checks**. AP recorded the payment and released it, but the payee has not presented it yet. Keep it on the bank side, but age it. A check that sits for one month may be normal. A check that sits for several months usually points to a void, reissue, stale-dated item, or an escheatment issue waiting to happen. Support matters here. List each timing item by date, amount, reference number, and source. Teams that carry one lump-sum line for "outstanding items" usually create extra work for the reviewer and hide old exceptions. ## Book-side adjustments that need entries Book-side items usually come from the bank first. If the statement shows cash activity that is not in the general ledger, record it before signing off on the reconciliation. Item Which side Journal entry needed Bank service fee Book side Usually yes Interest earned Book side Usually yes NSF or returned check Book side Usually yes Debit or credit memo Book side Usually yes The journal entry is often simple. The follow-up usually is not. A bank fee may post to expense and cash in seconds. An NSF item often needs coordination with AR so the customer balance is reopened correctly. A debit memo might relate to merchant fees, loan payments, treasury activity, or a bank error. Staff accountants should not guess based on the memo text alone. Trace it to the underlying business event and assign it to the right account the first time. ## The common judgment mistakes The first mistake is posting an entry for a timing item. That creates a second problem on top of the first one. Deposits in transit and outstanding checks are reconciling items, not corrections. The second mistake is assuming a book-side item will "wash out" next month. It will not. Bank fees, direct debits, reversals, and returned payments stay unresolved until someone records them in the ledger. The third mistake is rolling old items forward without challenge. Controllers watch stale reconciling items because they often expose process issues upstream. An old deposit in transit can signal a cutoff error or missing support. A cluster of NSF items may point to weak cash application controls. A growing list of old checks usually means AP cleanup is behind. ## What good teams do differently They assign ownership by item type. Treasury or accounting handles bank fees and account analysis charges. AR owns returned customer payments. AP reviews stale checks. That sounds basic, but it is what keeps the reconciliation from turning into a parking lot for unresolved problems. They also use exception rules. For example, flag deposits in transit that do not clear in the next statement cycle, and flag checks older than a set threshold for review. In high-volume environments, that matters more than making the worksheet look tidy. Automation can match the easy items. Staff should spend their time on the exceptions that need judgment. # Troubleshooting When Your Reconciliation Fails to Balance When a bank recon format doesn't balance, don't start with exotic explanations. Most failed reconciliations come from process misses, not rare accounting problems. Numeric highlights three common failure points: forgetting to record bank-initiated charges, failing to clear prior-period reconciling items, and starting from a mismatched opening balance that signals an unresolved prior error ([Numeric's discussion of reconciliation failure points](https://www.numeric.io/blog/bank-reconciliation)). ![bank-recon-format-bank-reconciliation.jpg](https://cdnimg.co/676959fc-fff3-440b-8860-da6e53d455e3/c161f21f-f1dc-47b1-bc1d-d8dd8358f729/bank-recon-format-bank-reconciliation.jpg) ## The first places to look If the recon is off, walk this sequence before doing anything else: * **Opening balance**. Confirm it ties to the prior month's final adjusted balance. * **Statement period**. Make sure the bank activity and GL detail cover the same dates. * **Book-side bank items**. Scan for charges, interest, reversals, or debit memos that never made it into the ledger. * **Old reconciling items**. Review prior deposits in transit and outstanding checks to see whether they cleared or were wrongly carried forward. * **Math and sign errors**. Recheck every add and subtract. Many "mystery" breaks are spreadsheet mistakes. ## Symptoms usually point to the cause A reconciliation gap often tells you what kind of mistake you're hunting. * **A clean round-number difference** often means a missed fee, transfer, or manual entry. * **A difference that looks like reversed digits** suggests a transposition or amount-entry problem. * **A break that keeps returning month after month** usually points to a stale reconciling item or upstream process failure. * **A large unexplained opening difference** usually means the prior period was never resolved. > Don't force the current month to balance around a prior month error. Fix the opening balance first. That advice saves hours. Once teams start "plugging" current activity to compensate for old mistakes, every future reconciliation gets harder to trust. ## What a reviewer should challenge If you review recons, push on three things: 1. **Anything old with no explanation** 2. **Anything grouped without transaction-level detail** 3. **Anything labeled "timing" for more than one cycle without evidence** A reconciliation that balances but contains stale unsupported items isn't done. It's just temporarily quiet. # Automating Reconciliations for Modern Teams Manual reconciliation teaches the discipline. Automation removes the parts humans are worst at doing repeatedly. The strongest setups use a mix of bank feeds, accounting software matching rules, and document extraction for statements or backup that still arrives as PDF. That matters in logistics, manufacturing, and multi-entity environments where not every bank account behaves the same way and not every source file lands in a clean import format. ## Where automation actually helps Automation is most useful in three places: * **Transaction ingestion**. Pulling statement activity into structured rows instead of retyping line items. * **Matching**. Auto-pairing obvious book-to-bank transactions so staff focus on exceptions. * **Exception handling**. Surfacing unmatched items, stale checks, and recurring bank-originated entries for review. For teams working through scanned statements or emailed PDFs, a document extraction layer can be more valuable than another spreadsheet macro. One example is [DigiParser](https://www.digiparser.com/), which extracts bank statement data into structured CSV, Excel, or JSON for downstream reconciliation workflows. That doesn't replace accounting judgment. It removes manual transcription from the process. A separate control layer still matters. Teams should check imported balances, verify statement period completeness, and confirm that mapping rules didn't misclassify transactions. Automation shortens the path to the exception list. It doesn't eliminate review. ## Good automation still follows accounting logic The best workflows preserve the same discipline as a manual bank recon format: * **Tie opening balances to the prior period** * **Separate timing items from book adjustments** * **Attach support to exceptions** * **Require preparer and reviewer accountability** If you're evaluating your wider finance stack, especially in Australia, it's worth comparing [ATO compliant accounting solutions](https://awts.net.au/blog/best-accounting-software-for-small-business-australia/) alongside your reconciliation process so bank feeds, GL posting, and compliance needs fit together. A practical next step is adding automated checks before the recon starts. This guide to using a [bank statement checker](https://www.digiparser.com/blog/bank-statement-checker) is useful when your team wants to validate statement structure and transaction data before matching begins. The teams that get the most value from automation don't use it to avoid reconciliation. They use it to spend less time typing and more time investigating the small set of items that need an accountant's attention. If your team is still copying bank statement lines into spreadsheets by hand, [DigiParser](https://www.digiparser.com/) can help turn statement PDFs and similar documents into structured Excel, CSV, or JSON files for reconciliation and downstream accounting workflows. That's especially useful when close speed depends on getting clean transaction data into the process early. * * * [See all posts](/blog) Automate recurring documents next: [invoice parser](/solutions/invoice-parser), [purchase order parser](/solutions/purchase-order-parser), and [extract data from PDF](/solutions/extract-data-from-pdf) hub. ## Transform Your Document Processing Start automating your document workflows with DigiParser's AI-powered solution. [Start Free Trial](https://app.digiparser.com/auth/join)[Schedule Demo](/contact)