Reconciliation automation with human control

Public roles at Gusto, Figma and Stripe assign reconciliation, close and flux-analysis work to finance professionals. These sources establish advertised responsibilities, not the companies’ internal tooling or an automation gap. For another team, they frame a practical question: which repeatable data checks can software support while account ownership, accounting policy and posting approval remain with authorised people?

What the Job Postings Literally State

Public finance roles describe specific close deliverables. Gusto’s Revenue Accountant posting includes "Prepare monthly journal entries, subledger reconciliations, and supporting schedules for retirement revenue streams." This establishes an advertised monthly responsibility; it does not describe the systems used to complete it.

Figma’s Senior Accountant posting includes "Own month-end and quarter-end close activities, including journal entries, accruals, account reconciliations, and financial reporting for your assigned areas." A separate Senior Analyst posting includes "Contribute to the monthly and quarterly close process, including balance sheet reconciliations and flux analyses." Neither posting reveals workflow volume or implementation.

Stripe’s Entity Controller posting includes "Manage the monthly close of US GAAP books and local books, including balance sheet reconciliations, supporting schedules, flux analysis, and reporting deliverables." Together, the listings establish assigned close, reconciliation and variance-analysis duties—not a shared architecture, missing product or measured business outcome.

Identifying the Shared Accounting Closing Responsibilities

The advertised duties include preparing entries and schedules, reconciling detail to ledger balances and explaining period changes. Some steps may be repeatable, but cadence and terminology alone do not show which parts are manual, how exceptions are resolved or which controls already exist.

A job description proves that a duty exists, not that the employer lacks software. Before proposing automation, inspect one authorised close cycle and distinguish required professional analysis from avoidable collection, comparison or reformatting work.

For another team, a useful boundary is to let deterministic software preserve source data, run approved comparisons and surface exceptions while authorised finance owners retain policy interpretation, journal-entry approval and reporting responsibility. This is a proposed design boundary, not a description of the cited companies.

• Source-to-staging completeness and control totals.
• Approved subledger-to-ledger comparison rules.
• Explicit exception states, ownership and supporting evidence.
• Reviewer decisions and downstream posting through existing controls.

For a bounded reconciliation workflow, YAS can compare current tools with a limited integration and define the evidence, exception and approval model: YAS builds custom software.

Determining Internal Recurrence and Workflow Boundaries

Start with an authorised sample from one account or subledger. Measure source collection, transformation, matching, exception research, review and rework separately. Record item volume, elapsed time, reviewer corrections and unresolved states rather than relying on a generic ‘month-end is manual’ description.

Map the actual systems and supported exports or APIs. Test whether existing ERP, close-management, reconciliation or integration features already cover the recurring handoff. A custom build is only one option after configuration and process changes are evaluated.

Use the observed exception rate, ownership model and control requirements to compare existing software with a bounded custom component, following the build-versus-buy questions in

Low-code orchestration may be suitable for approved transfers and notifications; specialised code may be justified for typed reconciliation logic, evidence retention or exception handling. Compare those responsibilities explicitly in n8n automation vs custom workflow software.

Minimal Internal Software Architecture for Reconciliation

If a material gap remains, begin with one source, one approved comparison and one review destination. A pilot can ingest a versioned extract, validate expected fields and control totals, apply approved matching rules and produce a review package. It should not attempt to automate the whole close or silently post entries.

Preserve the source snapshot, extraction time, schema and rule version. Represent missing, duplicate, late or conflicting records explicitly. ‘Parsed successfully’ does not mean complete, accurate or correctly classified, and a technically balanced result does not establish the appropriate accounting treatment.

Use supported connectors for transport when they meet the access, retry and audit needs; reserve custom logic for a measured gap. The trade-off is discussed in

Before maintaining a bespoke component, compare its operational ownership, control surface and recovery obligations with established products, using custom software vs off-the-shelf SaaS.

Deterministic Pipeline Design Before Generative Commentary

Use deterministic code for schema validation, control totals, currency-aware arithmetic and approved matching rules. Tolerances, materiality and sign conventions must be defined by the finance owner for the specific account; ‘down to the cent’ is not a universal control rule.

Calculate period changes and threshold flags reproducibly, but retain the inputs and rule version. A threshold can prioritise review; it cannot determine the accounting explanation, materiality conclusion or posting treatment on its own.

A language model may draft a variance explanation from permitted structured evidence after deterministic checks. Keep the draft visibly separate from verified fields, cite the supporting records and require an authorised reviewer to correct or reject it. Valid JSON and fluent prose are not evidence of factual accuracy.

Keep the pilot small enough to test with representative exceptions and a manual fallback, using the guide to scope an MVP without waste.

Exception Routing, Traceability, and Audit Trails

Define explicit states for missing source data, unmatched balances, unsupported currencies, duplicate records, late adjustments and unresolved ownership. Routing may use approved account mappings and thresholds, but each exception needs visibility, an owner and a manual path; an unrecognised item must not silently become zero or resolved.

Record source references, extraction and rule versions, significant state changes and reviewer actions with appropriate access and retention controls. Append-only storage can support traceability, but it is not automatically immutable, complete or compliant. Safe retry must avoid duplicate downstream work.

Traceability should let a reviewer reconstruct which source, rule and decision produced a review package. Test that reconstruction and recovery with representative corrections; software cannot guarantee that every source record, judgement or error has been captured.

Human Review Gates and Accounting Sign-Offs

The proposed workflow should not post a journal entry solely because balances match or a generated explanation sounds plausible. Posting authority, segregation of duties and review thresholds belong to the organisation’s approved finance and access-control policies.

Present source evidence, comparison results, unresolved exceptions and any model draft as separate layers. An authorised preparer and reviewer can request evidence, adjust the proposed treatment and approve or reject the next action through the existing ERP and close process. A recorded approval is useful evidence, not a guarantee of correctness.

Human review is a control to define and test, not a decorative final click. The team should measure reviewer corrections, late adjustments, failed handoffs and whether approved entries followed the normal downstream controls. Professional accountability remains with the organisation’s authorised finance roles.

Diagnostic Steps for Internal Finance Operations

Map one recent close cycle, then identify a recurring handoff where verified data collection, comparison or evidence packaging materially delays an authorised decision. Compare current tools and process changes before proposing new software.

To discuss a first scope, bring one sanitised source example, the approved comparison rule, the exception owner, review destination and current delay. YAS can assess configuration, integration and a bounded custom component, including permissions, acceptance tests, monitoring, recovery, manual fallback and handover. The cited vacancies are not YAS client evidence or measured savings.

Estimate implementation, review, security, recovery and ongoing ownership rather than only initial development, using the framework for workflow automation cost.

Checklist for a bounded reconciliation pilot

1. Choose one approved account or subledger and document the permitted source, owner and close deadline.
2. Capture the source snapshot, control total, schema and extraction time before transforming data.
3. Measure collection, comparison, exception research, review and rework separately across representative cycles.
4. Document currency, tolerance, sign, period and materiality rules with the authorised finance owner.
5. Preserve missing, duplicate, late, conflicting and unsupported records as explicit exception states.
6. Test whether current ERP, close-management and integration features cover the measured handoff before building.
7. Define access, retention, segregation of duties, safe retry, recovery and manual fallback before connecting live finance data.
8. Set acceptance criteria for reconciliation accuracy, reviewer correction, exception visibility and downstream approval—not generic time savings.

A public job duty establishes an assigned responsibility, not an absent system. A sound pilot starts with one measured reconciliation handoff and keeps accounting decisions with authorised people.