Open finance skill
Which bank transactions do not match the ledger?
Compare invented bank and accounting transaction lists. Find supported matches and list the differences that still need review.
From finding to decision
Match individual bank transactions with the accounting records before trusting the total. Repeated equal-value charges, reversals and transactions that clear later each need their own explanation.
Every bank transaction and accounting difference has an explanation supported by records for the selected statement period.
A reviewer accepts how each unresolved item will be treated before any correction.
Level diagnostic method reviewed . Apply it to the selected records and accounting policy; the teaching example does not resolve a live account.
Financial evidence in practice
Yes. Two lists can sum to the same amount while referring to different occurrences. Match native identity, account, date and signed economics, then explain outstanding items against the statement. Repeated equal charges can both be legitimate.
Both fictional lists total a $26 outflow. Only occurrence A matches. The second bank row is September 29; the unresolved ledger row is October 2, so the lists span different cutoffs. Equal totals and repeated $13 values cannot prove the second match.
Invented teaching inputs in USD cents. Incoming amounts are positive and outgoing amounts negative. A card charge credits its liability account.
{
"fictional": true,
"unit": "USD cents",
"id": "bank-identity",
"totalsTie": true,
"matchedIds": [
"A"
],
"unmatchedBank": [
"B"
],
"unmatchedLedger": [
"C"
],
"decision": "Same amount and equal totals do not prove occurrence identity",
"limitation": "This is teaching arithmetic from supplied invented inputs, not source authenticity, financial assurance or authority to post."
}Download the code and input into one folder, then run:
node reproduce.mjs bank-identity.input.jsonThe code checks declared units and identities and refuses unsupported inputs. No browser or customer account is used. Source authenticity and accounting approval require separate evidence.
Reviewed 2026-10-06. Level financial-control guidance, with visibly fictional teaching examples. The example shows a control boundary, not a measured customer outcome or industry benchmark.
Read this content revision history
Continue with the related financial decision →Guided synthetic example
A customer payment appears in the bank, but the amount recorded in the ledger is different.
An illustrative allocation is 15% collecting records, 20% applying checks, 10% flagging results, 25% investigating reasons, 20% finance review and 10% choosing an action. These percentages were not measured across engagements. Actual effort varies with data quality, complexity and the issue found.
| Source | Reference | Date | Amount |
|---|---|---|---|
| Bank | Deposit B-104 | Jul 8 | $12,480 |
| Ledger | Receipt L-221 | Jul 8 | $12,840 |
A reviewer-set $1 amount tolerance can screen possible matches; it does not approve them. Require a supported reference and date, then explain and approve any non-zero difference before applying a match. The same-date pair shown is only a candidate; different references and a $360 variance leave both records unmatched.
Needs review
A candidate bank/ledger pair differs by $360; both records remain unmatched pending supporting evidence.
At Level, we record the review logic, known explanations, and questions our finance professionals use in this situation. AI applies that documented human judgment to organize the most plausible reasons, without pretending it knows which reason is true.
Possible reasons to investigate
The difference could be a posting error, processing fee, partial payment, or a transposed amount. The check cannot choose among them.
In a Level engagement, a Level finance professional validates the source evidence, challenges the AI-assisted analysis, and decides which explanation is supported.
Inspect the deposit support and customer remittance before closing the account.
Each skill uses an independent synthetic scenario. Shared month labels do not mean the examples describe one company or a single financial period.
Accounting review examples
These are additional review scenarios to discuss with your accountant or automation team. They describe what to check and when a person needs to investigate. They are illustrative, not software tests you can run here or proof of how a particular vendor works.
Test: Follow one pay run through the payroll register, journal, liabilities, bank payment, bank-feed match and job-cost allocation.
Expected: Explain whether the entries are a duplicate, an accrual, a settlement or a match before changing accounts or deleting anything.
Pause and investigate when: Pay-run records are missing or it is unclear which system posted the entry.
Use this system
The JSON download is a sample record file to inspect with an AI assistant or developer. It is not a file to upload into your accounting software.
Website example JSON and registry: CC BY 4.0 (attribution required). Downloadable toolkit ZIP: MIT. Each version identifies its own frozen examples.
Developer preview: AI-assistant helper (MCP)
This tool call returns fixed, invented sample records only. It does not connect to your books. Read the setup instructions.
run_synthetic_example {"slug":"reconcile-account"}This check organizes evidence and surfaces exceptions. A person with finance domain expertise still needs to interpret the result, validate the source records, and discuss the operating decision.
Open source does not mean open client data. We publish reusable finance tools, checks, templates, and playbooks. Client records, workpapers, credentials, communications, and private configurations remain confidential.
Use it yourself, or bring us the messy part
Tell us where the records stop making sense. We will reply with the first check to run, the records it needs, and the decision that still needs human finance judgment.
Install the free skills yourself