Use an AI coding agent to build a cash reconciliation checker

Give an AI coding agent one financial task with an explicit business rule, fictional inputs and an acceptance test owned by someone other than the code author. Let it build in a restricted development workspace, then run and review the resulting program independently. This guide takes that approach through a cash reconciliation checker you can download and run locally, including a deliberately broken version that the tests must reject.

The design choices below are our analysis of how to solve this operating problem.

The starting problem is familiar: someone receives an internal cash file and a bank file, lines them up in a spreadsheet and investigates the differences. An operations lead wants a repeatable comparison. An engineer wants a specification that says what to do with a missing account, a different currency or a balance one cent apart.

Those questions decide whether the tool is useful. The coding agent helps turn the agreed answers into code and tests. It does not decide which discrepancy the firm can ignore.

The downloadable build kit contains the completed Python implementation, two fictional CSV files, 15 acceptance tests, an agent work order and a fault demonstration. The local program and tests were executed while preparing this guide. The exercise runs offline and uses no model API at runtime. It demonstrates an AI-assisted development task, rather than an AI making accounting decisions.

Download the code, sample data and tests (ZIP)

Start with one result operations can use

Build a review file that says which cash balances agree, which differ and which appear on only one side. Keep the result tied to the exact input files. Do not add posting, FX conversion, tolerance approval or client reporting to the first version.

For the worked example, compare a single legal entity's closing balances for 30 September 2026. Assume both exports already use the same account identifiers, currencies and definition of closing balance. A real implementation must establish those agreements with the people responsible for the source systems. A bank's value-date balance and an internal trade-date balance can differ legitimately; matching their column names does not make them comparable.

I want these choices written before the assistant starts. Otherwise, a convenient implementation choice can quietly become an operating policy. A request to “remove small differences” looks like a minor code change until someone asks who authorised the tolerance.

Choose a small tool stack you can maintain

The reference implementation uses Python's standard library: csv to read the exports, Decimal for amounts, hashlib to identify file bytes and unittest for the acceptance suite. There are no external Python packages to install. It was run on Python 3.14.2.

Python's decimal documentation explains why decimal values created from strings are appropriate when exact decimal arithmetic matters. Here the parser accepts at most 15 integer digits and exactly two decimal places. It rejects NaN, exponent notation, commas and extra precision instead of guessing how to repair them. These limits keep this exercise small and its arithmetic explicit; they are not a universal currency policy.

Choose the firm's approved coding assistant for the development work. The design does not depend on a particular model or subscription. What matters for this task is that you can give the assistant the specification, inspect its changes and restrict its access. The completed checker needs no assistant after the code has been built.

Use Git for version history if the team already works that way. Use the organisation's existing review and build service for release checks. Introducing another orchestration platform would add work without improving this four-column matching problem.

AWS's financial-services AI development guidance distinguishes instructions that influence an agent from automated checks and actual permission boundaries. The example below applies that distinction to a small cash tool. The written work order helps the assistant follow the task; the maintained tests check specific behaviour; access restrictions limit what the process can reach. None substitutes for the others.

Put the agent and the reviewer on separate paths

The accompanying architecture diagram separates the restricted agent workspace from the independent review environment and the human release decision.

The working route is:

1. Operations defines the comparison and supplies approved fictional examples.

2. The engineer puts the specification and examples in a development workspace.

3. The coding assistant proposes checker.py and explains its changes.

4. A separate reviewer tests the candidate against a maintained acceptance suite.

5. Operations checks the resulting exceptions against the agreed examples.

6. A release owner decides whether that exact version can enter a supervised pilot.

The download puts the reference code and tests together so you can learn from them. In an institutional build, keep the acceptance baseline outside the assistant's writable workspace. A candidate that rewrites its own expected answer can make a weak test look reassuring.

A folder name is not isolation. Before running unknown generated code, use the organisation's disposable development environment with appropriate operating-system and network restrictions. Give the exercise no customer files, production credentials or release permissions. The Python interpreter executes code; a test harness does not make arbitrary Python safe to run.

Step 1: prepare the two source files

The exact header is:

entity,account,currency,as_of,balance

entity,account,currency,as_of,balance

entity,account,currency,as_of,balance

The internal file contains:

ENT_01,CASH_01,EUR,2026-09-30,1000.10
ENT_01,CASH_02,EUR,2026-09-30,250.00
ENT_01,CASH_03,USD,2026-09-30,10.00

ENT_01,CASH_01,EUR,2026-09-30,1000.10
ENT_01,CASH_02,EUR,2026-09-30,250.00
ENT_01,CASH_03,USD,2026-09-30,10.00

ENT_01,CASH_01,EUR,2026-09-30,1000.10
ENT_01,CASH_02,EUR,2026-09-30,250.00
ENT_01,CASH_03,USD,2026-09-30,10.00

The bank file contains:

ENT_01,CASH_01,EUR,2026-09-30,1000.10
ENT_01,CASH_02,EUR,2026-09-30,249.99
ENT_01,CASH_04,GBP,2026-09-30,15.00

ENT_01,CASH_01,EUR,2026-09-30,1000.10
ENT_01,CASH_02,EUR,2026-09-30,249.99
ENT_01,CASH_04,GBP,2026-09-30,15.00

ENT_01,CASH_01,EUR,2026-09-30,1000.10
ENT_01,CASH_02,EUR,2026-09-30,249.99
ENT_01,CASH_04,GBP,2026-09-30,15.00

Both complete files, including headers, are in build-kit/data/. The parser requires UTF-8, limits each file to 1 MB, checks the date and rejects missing or extra fields. Entity and account identifiers use uppercase letters, digits, underscores or hyphens. The teaching currencies are EUR, USD and GBP.

That narrow input contract is intentional. If the actual export uses localised numbers, multiple balance types or duplicate account rows that should be aggregated, add a separately specified transformation before this comparison. Keep its source record and rule version available. Do not let the assistant silently aggregate whatever happens to arrive.

Step 2: give the assistant a buildable task

Use the included agent-task.md and AGENTS.md as a work order. If your assistant uses a different instruction-file convention, supply the same instructions through its approved mechanism. The work order says:

Build a read-only CSV comparison. Use exact decimal strings. Match on entity, account, currency and date. Missing data remains an exception. Reject ambiguous inputs. Print the review result with source hashes. Do not change the input files, introduce a tolerance or deploy the program.

Ask for the changed files, test commands, observed outputs and remaining limitations. Give the assistant the valid sample and the business cases, while the reviewer retains the maintained acceptance suite. New tests can be proposed; changing a business expectation requires a separate decision.

To reproduce the development exercise, keep the completed download as your reference. Create a separate working directory containing only the README, work order and fictional input files. Ask the assistant to create checker.py there. This lets you compare its implementation with the supplied reference without overwriting your starting point.

The useful AI work is translating the specification into a parser, comparison function, command-line interface and failure handling. A financial engineer then reviews whether those components implement the agreed semantics. Speed is worth measuring after that review, including any correction work.

Step 3: compare the complete account population

An inner join would discard accounts that exist on only one side. The implementation takes the union of both key sets, then classifies each record. Its central calculation is small:

left, right = internal.get(key), bank.get(key)
difference = left - right if left is not None and right is not None else None
status = ('MISSING_INTERNAL' if left is None else
          'MISSING_BANK' if right is None else
          'MATCH' if difference == 0 else 'BREAK')

left, right = internal.get(key), bank.get(key)
difference = left - right if left is not None and right is not None else None
status = ('MISSING_INTERNAL' if left is None else
          'MISSING_BANK' if right is None else
          'MATCH' if difference == 0 else 'BREAK')

left, right = internal.get(key), bank.get(key)
difference = left - right if left is not None and right is not None else None
status = ('MISSING_INTERNAL' if left is None else
          'MISSING_BANK' if right is None else
          'MATCH' if difference == 0 else 'BREAK')

The complete source validates every input before reaching this calculation. It rejects a snapshot containing a different entity or date, so the program cannot produce a plausible partial reconciliation from a mixed file.

Run the supplied implementation from the build-kit directory:

python checker.py data/internal.csv data/bank.csv --entity ENT_01 --as-of 2026-09-30

python checker.py data/internal.csv data/bank.csv --entity ENT_01 --as-of 2026-09-30

python checker.py data/internal.csv data/bank.csv --entity ENT_01 --as-of 2026-09-30

The result is JSON with four rows:

The output also records authority: review-only, the selected entity and date, and SHA-256 hashes of both source files. A hash identifies a particular set of bytes for comparison. It does not prove the file came from the bank, establish approval or prevent someone changing both a file and its recorded hash.

The first interface can remain a command-line job with a review file. Add a user interface when you know which action the reviewer needs: opening the source, assigning a break, recording a decision or checking a rerun. A colourful dashboard will not settle a missing cash account.

Step 4: run the acceptance cases, then prove one can fail

Run:

python -m unittest discover -s acceptance -v
python prove_gate.py

python -m unittest discover -s acceptance -v
python prove_gate.py

python -m unittest discover -s acceptance -v
python prove_gate.py

The first command runs 15 tests. They cover exact matches, a one-cent break, negative balances, missing accounts, currency separation, duplicates, wrong entities, stale or invalid dates, blank and non-finite amounts, excessive decimal places, empty files, changing source hashes and reproducible output. The test helper also checks that successful comparisons leave the input bytes unchanged.

The second command demonstrates the difference between a passing test suite and a test suite that catches a relevant defect. It makes a disposable copy of the checker and changes the matching rule so that a difference of one cent becomes a match. It then runs the same maintained acceptance suite against that copy.

In the recorded local run, the reference candidate passed all 15 tests. The modified copy failed test_one_cent_break, because it returned MATCH where the operating rule required BREAK. The demonstration exits successfully only when the reference passes and the faulty copy fails. Both logs are included in the kit, and the delivered reference code remains unchanged.

That result supports one precise conclusion: this test detects this tolerance defect. It does not establish coverage of every possible defect or the performance of any commercial coding assistant. Extend the suite around the actual export format and the consequences of a wrong result.

For a separately generated candidate, the reviewer can point the maintained suite at it using CANDIDATE_FILE. The README gives both PowerShell and POSIX commands. Run this comparison inside the controlled execution environment, because loading the candidate executes its Python code.

Step 5: put the checks in a release process the agent cannot approve

Retain the specification, candidate version, maintained test version, observed output and reviewer decision together. If the code changes after review, rerun the relevant checks against the changed version. Record why a test was added or its expectation changed.

For teams using GitHub, protected branches can require review and passing checks before merge. Availability depends on the repository and plan. Configure the restrictions outside the agent's task, account for administrator or bypass privileges, and give the acceptance job a distinct name. Merely including a workflow file in a repository does not prove those requirements are enforced.

GitHub's secure workflow guidance recommends minimal token permissions and warns about privileged workflows running untrusted pull-request code. A check for this offline example needs no customer credentials or production network access. Do not connect an unreviewed candidate to those resources to make the test feel realistic.

This download contains the local acceptance exercise, not a preconfigured hosted CI service. Your engineer should wire its commands into the firm's existing service and demonstrate that a failing candidate cannot reach the release path. Test that configuration with a harmless failed change. An instruction saying “do not merge” is not the test.

Step 6: pilot the operating result

The first business pilot should compare the checker and the current process on the same approved historical period. Agree which source records constitute the complete population. Have operations review all unexpected classifications and record the explanation.

Track preparation time, review time, correction time, missing-source incidents and defects that reached the review file. Measure total completed work, not only the seconds spent executing Python. This build does not contain measured customer savings; your pilot supplies that evidence.

Before a live job exists, name the source owner, the reconciliation owner, the engineer who maintains the parser and the person who can suspend the job. Specify where the output is kept, who can see it and what happens when an input is late. Keep the existing manual route available until the new workflow has met the institution's acceptance criteria.

For a Luxembourg or European financial firm, the appropriate data handling, outsourcing, change approval and retention requirements depend on the entity and deployment. Bring the firm's security, compliance and business owners into those decisions before live data or operating authority is introduced. This technical exercise supplies a starting implementation and evidence, not a legal determination.

The next useful step is to run the four-row example, inspect its exceptions and ask your engineer to reproduce one change through the same review process. If you want Asset Velocity to adapt this into an institution-owned workflow connected to your actual sources and review process, bring the sample export structure and the operating rule. That is enough to start a concrete implementation discussion.

Implementation resources

• Download the implementation pack (ZIP)

• Open the architecture diagram