reconcile
Verify that opening balances plus movements equal closing balances, showing both sides and variance to catch arithmetic errors in financial reconciliations.
Instructions
Check that opening + movements = closing, and show both sides and the variance.
Use this whenever a period of numbers is supposed to add up: a bank reconciliation, a roll-forward, a statement extract, a ledger movement summary. It is the check that does not depend on how plausible any single figure looked. If the arithmetic does not close, the numbers are wrong even if every field looked fine on its own — that is the failure that survives field-level validation and reaches a report.
This tool is deterministic arithmetic. It has no opinion about whether the movements are the right movements; it only states whether the given opening, movements and closing are consistent with each other.
Args:
opening_balance: The balance at the start of the period, as a number or a
numeric string. Example: 1000.00.
movements: The changes during the period, as an array. Each element is
either a signed number (250.0 increases, -40.5 decreases) or an
object {"amount": 250.0, "direction": "in", "label": "INV-1001", "date": "2026-04-03"}. Use "direction": "out" for a decrease, or
pass the amount as a negative number — never both. Passing an outflow
as a positive amount is the most common cause of a variance, so state
the direction explicitly when you can.
closing_balance: The balance at the end of the period, as a number or a
numeric string. Example: 1210.00.
tolerance: The largest variance to accept as closing, in the same units
as the balances. Default 0.01, which suits two-decimal currency.
Set it to 0 for an exact check.
Returns:
An object with:
ok (true only if the arithmetic closes),
verdict ("clean" | "does_not_close" | "inputs_rejected"),
opening_balance, movements_net, expected_closing_balance,
reported_closing_balance, variance, absolute_variance, tolerance,
closes (true/false, or null when the inputs were incomplete),
arithmetic_is_reliable, movement_counts, movement_totals,
movements (each parsed movement with its signed amount),
findings, and guidance.
`findings` always shows both sides of the equation in words, so the
variance can be read without recomputing it. When the variance exactly
equals the size of one movement, an extra finding says so — that is
arithmetic, not a guess, and it is usually the answer.Raises:
Nothing for bad data. A movement that cannot be read is reported in
findings and excluded, and closes becomes null with
arithmetic_is_reliable: false, because a total over an incomplete set of
movements must never be reported as a pass. Genuinely malformed arguments
(movements that are not an array at all, or a non-numeric opening or
closing balance) return the same envelope with verdict set to
"inputs_rejected".
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| movements | Yes | ||
| tolerance | No | ||
| closing_balance | Yes | ||
| opening_balance | Yes |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||