Finance records where every AI change has a basis and an approver

Reconciling invoices against contracts, fixing subscription quantities, correcting tax codes, chasing a mismatched payment — repetitive, high-volume, and exactly the work an agent is good at. It is also the work where a wrong value becomes a restatement.

ActionsLedger applies the control finance already expects from people to an agent: the thing that proposes a change is not the thing that posts it, each value cites its source document, closed periods are immutable, and the trail is append-only.

[ 01 / 03 ] · WHERE IT BREAKS // without a review layer //sha 4b227w

Amounts without a source document

A corrected invoice total that came from a model summary rather than the contract line. It reconciles today and fails the sample in the next audit.

CONTROL → DOCUMENT SPAN PER AMOUNT

Writes into a closed period

A late correction posts against a month that has already been reported. The books move after the fact, quietly.

CONTROL → IMMUTABLE PERIOD WINDOWS

One actor proposing and posting

The same credential drafts the adjustment and commits it. Segregation of duties exists on the org chart but not in the system.

CONTROL → SEPARATION OF DUTIES

Logs that only show success

The API returned 200. It does not tell you what the field was before, what it became, or on what basis — which is the only thing an auditor asks.

CONTROL → BEFORE/AFTER + VERDICT

[ 02 / 03 ] · THE REVIEW LOOP // propose, verify, merge //sha 6b86n2

Read the source of truth, not a summary

The agent reads contracts, invoices, payment records and the billing system with read-only credentials and produces proposed corrections with the exact document span behind each figure.

Deterministic checks first

Schema validation, value bounds, currency and tax-code validity, reconciliation tolerance and period status all run as code. A proposal that fails any check never reaches a reviewer.

Approval by materiality

Small in-tolerance corrections can auto-merge; anything above the materiality threshold, or touching tax, revenue recognition or credit notes, requires a named approver who is not the proposer.

An audit artifact, not a changelog

Each merge appends before/after values, document references, the policy verdict, the approver and the timestamp, with entry N committing to entry N-1 by hash — so backdating or deletion is detectable rather than invisible.

[ 03 / 03 ] · POLICY // what auto-merges, what waits //sha d4735e

Controls finance can point at

Reconciliation within toleranceAuto-merge with the matched document references recorded.

Amounts above materialityNamed approver, not the proposer. Source document required.

Tax codes and jurisdictionsHuman review. Validated against the code list as code.

Credit notes and refundsHuman review, always, with the reason captured in the entry.

Closed periodsBlocked. Corrections go to the open period with a reference to the original.

Bulk adjustmentsRate-limited and reviewed by class, never approved as a count.

finance — segregation of duties

agent                 read-only: contracts, invoices, ledger
proposer              cannot approve its own change
approver              named human, above materiality
merge worker          sole writer, open periods only
closed period         write blocked, fail closed

append-only trail: diff · document ref · verdict · approver
entry N commits to entry N-1 (sha256)
period status re-checked at merge time

Automate the reconciliation, keep the audit intact.

Evidence per amount, an approver who is not the proposer, immutable closed periods, and a trail you can hand to an auditor.

Start for free All use cases