Walk through a bank reconciliation
Start with a known bank opening, match two cleared movements and explain what changes when a payment is still outstanding.
PHP Ledger guidance: use this page with the matching release notes and evaluate the workflow using synthetic records.
What does bank reconciliation establish?
It compares a bank statement with posted ledger movements and explains the timing differences.
The bank and the ledger describe related evidence, but they do not necessarily show the same closing balance on the same day. A payment may be posted before it clears the bank. A bank fee may appear on the statement before it has been recorded in the books. Reconciliation identifies these differences and requires an explanation; it does not justify inserting an unexplained adjustment to make the totals agree.
This walkthrough uses synthetic domestic-currency figures in a self-hosted installation. Public-demo permissions do not allow bank-import and reconciliation writes. No bank connection or payment is initiated here. The CSV represents an independently obtained statement, and importing it does not create accounting postings. If you need automated bank feeds or payment initiation, assess those as separate capabilities.
What must be true before the first statement?
Establish a matching opening bank position and clear the first statement’s historical boundary.
Use a bank ledger account with the intended role and the same supported currency as the statement exercise. The first statement needs a trustworthy baseline. The application checks the opening position and earlier outstanding activity; unresolved movements before the first statement’s start can prevent acceptance. Do not pick a later start date merely to hide older unmatched entries. Resolve the baseline with supporting records or use the appropriate reviewed cutover.
For this example, begin with a reconciled opening bank balance of 1,000.00. Two later events are already posted: a receipt of 125.00 on 2 September 2026 and an expense of 25.00 on 3 September. The ledger closing balance is therefore 1,100.00. The statement contains those same cleared events and closes at 1,100.00. Keep their source references available before importing.
How do you prepare the statement CSV?
Use the exact documented headers and one positive money direction on each statement row.
date,reference,description,money_in,money_out
2026-09-02,BANK-001,Synthetic receipt,125,0
2026-09-03,BANK-002,Synthetic expense,0,25Use UTF-8, ISO-formatted dates and plain decimals without currency symbols or thousands separators. The documented boundary is 500 data rows and 512 KiB. Each reference should be a durable unique bank reference for the account. Do not replace references with a new sequence every time the same statement is imported, because that obscures duplicate detection. Keep the original statement evidence alongside the prepared CSV.
The money-in and money-out columns express direction. A row must not contain two positive sides or an unexplained signed amount placed in the wrong column. Review the exported file itself after preparing it in a spreadsheet. Visual formatting and regional separators can change CSV output. For this exercise, the statement opening is 1,000 and net movement is 100, so the closing amount is 1,100.
What do you inspect before confirming import?
Check the bank account, statement dates, opening balance, movements and closing balance together.
- Select the intended company, book and bank account.
- Enter the statement period and supplied opening and closing amounts.
- Upload the prepared CSV and inspect the preview.
- Resolve invalid dates, duplicate references and arithmetic errors.
- Confirm the statement import only after the preview matches the source.
An imported statement is evidence to reconcile, not an instruction to post every row. The receipt and expense in this example already exist in the ledger. Posting them again from the CSV would duplicate bank activity and income or expense. If the bank shows a genuine event missing from the books, investigate and create the appropriate reviewed source through its normal posting flow, then return to reconciliation.
Keep the statement period explicit. Overlapping or inconsistent periods can make an apparent arithmetic match misleading. A deposit outside the selected range should not be pulled into the statement merely because its amount is convenient. Dates, references and narrative provide evidence alongside the amount.
How do you match the two rows?
Select the corresponding posted bank movement after checking direction, exact amount and source evidence.
| Statement reference | Statement movement | Ledger evidence |
|---|---|---|
| BANK-001 | Money in 125.00 | Posted receipt increasing bank by 125.00 |
| BANK-002 | Money out 25.00 | Posted expense reducing bank by 25.00 |
The application offers candidates using the exact amount and sign, with date proximity helping review. It does not make the accounting decision automatically. Two receipts of the same amount can both be valid candidates; inspect their source references and dates before choosing. A nearby date is a clue, not proof. Retain a clear explanation when the statement date differs from the posted date.
The supported matching path is one statement row to one eligible posted bank movement. Do not describe it as a split, aggregate or foreign-bank reconciliation workflow. If a bank combines several payments into one line, the simple example does not establish a supported matching solution for that situation. Preserve the evidence and evaluate the actual supported path before restructuring records.
What if a posted payment has not cleared?
Keep the outstanding movement visible and use its signed effect to explain the difference.
Extend the example with a correctly posted expense of 40.00 that has not yet appeared on the statement. The ledger bank balance is now 1,060.00, while the statement still closes at 1,100.00. The outstanding payment has a negative bank effect of 40.00. Statement closing 1,100 plus signed outstanding movement −40 equals ledger closing 1,060. This is an explained timing difference, not a reason to delete the expense.
| Measure | Amount |
|---|---|
| Statement closing balance | 1,100.00 |
| Outstanding posted payment | −40.00 |
| Reconciled ledger closing balance | 1,060.00 |
The direction matters. An uncleared receipt would increase the ledger relative to the statement, while an uncleared payment reduces it. Keep the underlying journal and source reference in the outstanding list. Do not use a single net difference to conceal several unrelated mistakes. Two wrong matches can cancel arithmetically and still leave the reconciliation incorrect.
When is the statement ready to complete?
Every statement row must be matched and the closing reconciliation must be supported, even if the arithmetic difference is zero.
What should you do next?
Review unmatched rows, outstanding ledger movements and the displayed closing comparison before completion. Zero difference is necessary evidence but not enough by itself. Confirm that each selected movement belongs to the same bank account and the appropriate period and has not been reused. A second reviewer, where available, should be able to follow the source references without relying on the preparer’s memory.
Completion protects the statement’s history. It also blocks new bank postings on or before the completed statement’s end date. Reopening an accounting period does not remove that reconciliation boundary. This prevents a later backdated event from silently changing a bank position already accepted as reconciled. Plan corrections with that safeguard in mind rather than assuming period controls are the only date restriction.
How do you handle a mistaken import?
Correct a draft statement through its supported unmatch and cancellation path, retaining a reason and history.
If a draft import is wrong, inspect the matches first. Remove draft matches as required, cancel the draft with an explanatory reason and then import the corrected evidence through the normal path. The history should show why the first import was abandoned. Do not directly delete statement rows or fabricate different references to hide the earlier attempt.
A completed statement is immutable in this workflow. If an error is discovered after completion, preserve the evidence and obtain a reviewed correction approach within the application’s permitted boundaries. Do not alter journal dates or source amounts in SQL. A correction that makes one screen look right while invalidating the accepted bank position is not a successful reconciliation.
When is this workflow the wrong fit?
Use another evaluated workflow when the bank data needs unsupported matching or automation.
This preview’s manual domestic matching is useful for understanding a controlled statement-to-ledger process. It does not establish automated feeds, split matching, payment processing or broad foreign-bank accounting. Finish this exercise by retaining the original statement, the import reference and the explanation of any outstanding items. Those records make the reconciliation reviewable after the screen is closed.
Questions before you continue
Check these boundaries before applying the procedure to a business installation.
Does a zero difference mean reconciliation is complete?
No. Every statement row must be matched and the selected movements and outstanding items must be supported.
Can period reopening change a completed statement?
No. The completed bank-statement boundary still restricts backdated bank postings.
Sources and next steps
Technical references and project behavior were checked on 16 September 2026; hosting access remains plan-specific.
The linked project files describe the current preview. Follow the instructions inside your exact downloaded package if a later release changes a command. Technical testing does not establish statutory compliance or independent accounting acceptance. See the project and preview limits.