Agentic month-end close: a guide for finance data teams

Key takeaways

• •Who this is for. The corporate finance data team that serves FP&A, the controller and the CFO: ERP and general ledger data, subledgers, close and consolidation, forecasting, spend and board reporting.
• •The problem today. Reconciliations, accrual checks and flux explanations are rebuilt in spreadsheets in the last week of every month, SAP and ERP extracts break after every upgrade or new company code, and audit evidence is assembled by hand from tickets and logs.
• •What changes. Subledgers are tied to the general ledger every day, flux is traced to the transactions behind it as the month runs, ERP changes are remapped at the boundary and evidence is captured as the work happens.
• •What stays with your people. Journal entries, adjustments, eliminations, published forecasts and board numbers: a named controller or finance leader approves each one, and no agent posts to the GL.
• •The result. A close that starts reconciled, and a finance data team that spends its week on forecasting products and analysis instead of rebuilding the tie-out.

The PRD for agentic finance data teams

This is the requirements document we would write with you for your team. Everything below expands on it.

What going fully agentic and autonomous means for finance data teams

• •Put your data pipeline on autopilot. SAP and ERP changes are detected at the boundary and extracts are remapped before the next report publishes, so a transport or a new company code stops breaking the close.
• •Run the data back office without the busywork. The work that fills the last week of the month moves to agents: subledger and bank reconciliations, accrual checks, intercompany matching and the first draft of every flux explanation.
• •Scale data without scaling headcount. A new entity, a new company code or a new planning driver is added in hours, so the number of entities and reports grows without the team having to.
• •Get the plumbing off your plate. A finance data team that ships forecasting and spend products instead of re-running the tie-out and answering "which number is right".

Who this is for

The team that owns finance as a data domain. At a software or industrial company it sits between the controller, FP&A and a central data organization, running the ledger and subledger marts on Snowflake or Databricks with dbt and Airflow. At a bank or insurer it supports corporate finance and the controller's group (the data behind financial reporting, not the regulatory submission, which is covered in risk and regulatory reporting data). Investment-side accounting is a different job and has its own playbook for fund accounting and investment data; card and payment ledgers are covered in card and payments data.

The titles: Controller, Assistant Controller, VP Finance, Head of FP&A, Director of Financial Systems, Finance Data Product Manager, Head of Finance Data, and the close managers and analytics engineers who report to them. These leaders answer to the CFO for the numbers and to the auditor for how the numbers were produced.

The product you ship

• •The ledger and subledger marts: GL, AP, AR, fixed assets, payroll and billing, as governed, reusable data products tied to each other.
• •Close and consolidation data: reconciliations, accrual and prepaid schedules, intercompany balances and consolidation inputs.
• •Management reporting: flux and variance packages, flash reports and the monthly operating review.
• •Planning data: actuals reconciled to the plan, drivers and the inputs behind the forecast.
• •Spend and vendor analytics: AP, procurement and contract data resolved to one vendor identity.
• •Board and executive reporting: the pack, its figures and the lineage behind each one.
• •Control evidence: the audit trail, access reviews and lineage that SOX and external audit ask for.

Where the week goes

• •Close compresses the month into five days. Reconciliations, accrual checks and flux are rebuilt in spreadsheets in the last week.
• •ERP changes break extracts. Upgrades, transports and new company codes alter fields in SAP, Oracle, NetSuite or Workday Financials, and reports go out wrong before anyone notices.
• •Breaks pile up. Bank, subledger, billing and GL data are matched by hand, and unmatched items age until close.
• •Definitions are contested. FP&A, the controller and the business each hold a version of revenue, headcount and spend.
• •Vendor names disagree. AP, procurement and contract data use different names for the same supplier, so spend by vendor is guesswork.
• •Evidence is a project. SOX and audit requests are answered from tickets, logs and spreadsheets.
• •The board pack is a scramble. Figures come from a dozen sources the week before the meeting and are argued over.

Add it up and upkeep is most of the team's week. Here is how a typical week splits today, and once agents own the back office:

Time spent on new data products moves from 14% of the week to 48%. Most of the rest becomes review: people steer and approve agent work instead of doing it by hand.

Then and now

These are the impact metrics we move for finance data teams:

• •Subledger tie-out: from about a week to 15-20 min
• •Flux explained: from about 3 days to about an hour
• •Audit evidence package: from about 2 weeks to 4 h

Across the routine work in this domain:

The biggest change is the intercompany match: from about a week to 15-20 min. Work that waited in queues finishes in minutes or hours, because agents detect, trace and verify in one pass.

Use cases, in depth

The month-end close that starts reconciled

Today. Reconciliations, accrual checks and flux explanations are rebuilt in spreadsheets in the last week of every month.

With Data Workers. Agents tie subledgers to the GL daily, flag unusual accruals and trace each material flux move to its drivers, then hold every adjustment for the controller.

What changes. Close week is review, not rework. The full guide is month-end close.

An SAP upgrade or new company code without a wrong report

Today. SAP and ERP extracts break after every upgrade, transport or new company code, and reports go out wrong.

With Data Workers. The Schema Evolution agent detects the change at the boundary and proposes the remap, Quality Monitoring ties the rebuilt report to the ledger, and the change reaches production only after review.

What changes. The report is right before it publishes. See SAP and ERP reporting.

Audit and SOX evidence on request

Today. Evidence for SOX and audit requests is assembled by hand from tickets, logs and spreadsheets, and the lineage for a reported number takes a week to reconstruct.

With Data Workers. Every agent action, approval and change lands in a tamper-evident audit trail, and the Data Context & Catalog agent traces a reported figure back to its sources on request.

What changes. The evidence package takes hours, and the auditor sees who proposed, who approved and what changed. See audit and controls.

Use-case guides for finance data teams

Each guide has the workflow, the agents and tools involved, the impact metrics and a one-entity pilot scope.

• •Month-end close: subledgers tied to the GL daily, accrual anomalies flagged, flux explained as the month runs.
• •Data reconciliation: bank, subledger, billing and GL data matched on every load, with each break traced to the record or rule behind it.
• •Flux and variance analysis: material moves detected daily, traced to transactions and drivers, and drafted for review.
• •FP&A forecasting: planning inputs kept fresh, governed and reconciled to actuals.
• •Intercompany and consolidation: intercompany balances matched daily so quarter-end eliminations start from agreed numbers.
• •Accruals and prepaids: schedules tied to contracts and invoices, with missing or stale entries flagged.
• •Agentic controllership: the controllership checklist run continuously, with every adjustment routed to the controller.
• •Audit and controls: SOX and audit evidence, access reviews and lineage generated on request.
• •Board and executive reporting: the pack assembled from governed definitions, each figure reconciled with lineage attached.
• •Cost intelligence: cost model inputs joined and tied to the GL so margins refresh with every close.
• •Real-time reporting: ERP, billing and warehouse data reconciled continuously, so a flash report is current any day of the month.
• •SAP and ERP reporting: ERP changes detected and extracts remapped before reports publish.
• •Spend and vendor analytics: one vendor identity across AP, procurement and contracts, with off-contract spend flagged.

Agents working together: Day two of the close

Every controller knows working day two. The subledgers have closed, the ERP extracts have landed, and somewhere between the AP aging, the bank files and the intercompany ledger there is a difference that nobody has found yet. This is the same morning run by Data Workers.

The setup

The finance marts run on Snowflake and dbt under Airflow, fed by SAP for the parent and a second ERP for an acquired subsidiary. They feed the close checklist, the flux package and the forecast. Autonomy in Autopilot:

• •Landing, tie-out checks and documentation upkeep: L2 today; a candidate for L3 on evidence.
• •Flux drafts and accrual flags: L2, reviewed by the account owner.
• •Journal entries, adjustments, eliminations and published numbers: L2 at most, held for the controller. No agent posts to the ledger.

The team scheduled one mission the week before: "Tie every subledger and intercompany balance to the GL by 08:00 on day two."

06:00: the extracts land

The Airflow run finishes. The AP, AR, fixed asset and bank files are loaded, and the subsidiary's ERP export arrives with one changed field.

06:04: confirm what landed

Connectors agent checks each source and confirms the loads are complete and on time. A late bank file for one entity is flagged before anything downstream reads it.

Schema Evolution agent sees the subsidiary's changed field, maps it into the model and validates compatibility with the existing marts.

06:20: tie it out

Quality Monitoring agent runs the checks the close depends on:

• •AP, AR and fixed asset subledgers tie to the GL control accounts.
• •Bank balances tie to cash.
• •Intercompany balances agree between each pair of entities.
• •Accrual and prepaid schedules tie to the contracts and invoices behind them.

Two things do not tie: a 41,000 difference between an intercompany pair, and a prepaid with no matching invoice.

06:40: trace the breaks

Incident Debugging agent traces the intercompany difference to an invoice booked in one entity in the old period and in the other in the new period. It traces the prepaid to a contract renewal that was never loaded. Neither is a data fault in the pipeline; both are accounting items, so it writes them up with the records involved.

07:05: link the flux

Data Context & Catalog agent links each material flux move to the source transactions and the governed definitions behind it, so the reviewer can click from a variance to the lines that caused it.

07:30: hold what needs a person

Data Access & Governance agent assembles the proposed adjustments, the evidence and the lineage, and requests review. The Autonomous Data-Conductor checks that the tie-out numbers hold after the SAP remap and routes one decision to the assistant controller: the two items, their proposed treatment and the supporting records.

08:10: approved

The assistant controller confirms the cut-off timing item and asks the subsidiary to book the correction, and routes the prepaid to the account owner. Nothing is posted by an agent. The entries are posted by the people who own them, in the ERP, through your existing approval workflow.

09:00: the team starts the day

The close checklist shows every subledger tied, two items explained and open, and the flux package drafted for the top accounts. Nobody rebuilt a reconciliation in a spreadsheet.

What stays behind

• •Daily tie-out tests for every subledger, so the next close starts the same way.
• •A receipt for every change: who proposed it, who approved it and how to roll it back.
• •Updated Spellbook Data Catalog pages for every affected finance data product.
• •A reusable mission. The following month runs the same way, and the team can move the routine parts to L3.

Minute by minute

This is an illustrative example. The finance marts run on Snowflake and dbt under Airflow, fed by a parent ERP and a subsidiary ERP. Adjustments are held for the controller.

The agents on the job

Data Context Wizard holds one governed definition of revenue, bookings, headcount, spend and each account hierarchy. FP&A models, the board pack and every AI assistant finance uses answer from the same definitions, so the forecast and the ledger stop disagreeing. Autonomous Data-Conductor verifies the numbers that matter before the flash report and the board pack go out. Spellbook Data Catalog makes each finance data product discoverable for controllers, analysts and auditors, in plain English.

What goes on autopilot

Once a domain has earned it, this work runs on its own, and each item removes a problem your team deals with today:

• •Subledger, bank and intercompany tie-outs run every day, so the last week of the month is review, not rework.
• •ERP changes are remapped at the boundary, so an upgrade or a new company code no longer sends a wrong report to the CFO.
• •Flux is computed daily and linked to its transactions, so there is no last-day scramble to explain a variance.
• •Evidence is captured as work happens, so an audit request is an export, not a project.

Where your people stay in charge

Agents never get blanket access. Each domain has its own autonomy level, set by you, and it only rises when the receipts show the agents are reliable. Everything starts at L1, observing only; reversible upkeep such as reruns, staging fixes, documentation and cleanup is usually first to run on its own.

• •Journal entries and adjustments always go to a named approver: controllers sign them, and no agent posts to the general ledger.
• •Elimination and consolidation entries, accruals and prepaids shape reported results, so the account owner or controller approves each one.
• •Published forecasts, board materials and external numbers go to the CFO or the owner of the report, because directors, lenders and auditors rely on them.
• •SOX-relevant changes, such as a change to a control, a report that supports one or access to financial data, are proposed with a full diff and approved by the control owner.

Once a deployment has matured, here is how that ladder plays out across task classes:

Catalog and docs upkeep closes autonomously 88% of the time. For journal entries and adjustments, autonomous closure is 0% by design: every entry is prepared as a proposal with the supporting records and approved by a named person.

What happens when an agent is wrong

• •At L2 propose, nothing changes until a named person approves. The proposal shows the full diff, the accounts affected and how to roll it back. Unanswered requests expire and escalate.
• •L3 and L4 are where a domain can go next, on its own review record: acting on its own, with a rollback point on every change. Only the domain's owner raises its level, and if people start reverting the agents' changes, the domain pauses itself.
• •No agent approves or promotes its own work. Autonomy only grows on evidence, domain by domain, and repeated reverts pause the domain.
• •One org-wide stop halts all autonomous dispatch, and every action lands in a tamper-evident audit trail you can export with generate_audit_report.

How it fits your stack

Data Workers connects to what you already run: SAP, Oracle, NetSuite or Workday Financials; billing and AP systems; Snowflake or Databricks; dbt; Airflow; Tableau or Looker; the close and planning tools your team already uses. Each agent is an MCP server, so the same agents work inside Claude Code, Cursor or Codex and in Slack or Teams through Spellbook. Nothing migrates.

• •Runs in your infrastructure with your credentials and your model key. The hosted Autonomous Data-Conductor sees workflow metadata only, never rows. The VPC and air-gapped options matter when ledger data cannot leave your network.
• •Uses the access you already govern. Agents act under scoped service identities and your existing roles; every grant goes through provision_access and is logged. Sensitive ledger and payroll data stays limited to the roles allowed to see it.
• •Proposes changes as diffs in your dbt project, orchestrator and warehouse, with blast radius, tests and a rollback point, and applies them only at the autonomy level you set for that domain.
• •Open-source core. The Apache-2.0 community edition ships 11 agents and 160+ MCP tools, so your engineers (and your auditors' technologists) can read exactly what the agents call.

Governance and regulation

For a public company or one preparing to be, the data behind financial reporting sits inside internal control over financial reporting. The auditor looks at who changed what, who approved it and whether the number can be traced to its source. Data Workers keeps access scoped with provision_access, holds every change that touches reported results for a named approver, and records each action in a tamper-evident audit trail. Lineage for a reported number comes from trace_cross_platform_lineage. Segregation of duties is preserved: the agent that prepares a proposal never approves or posts it.

The standards your assessors apply are public: the PCAOB's auditing standard on an audit of internal control over financial reporting and the COSO internal control framework are listed in the sources. For how our controls map to SOX evidence, see how Data Workers helps with SOX, HIPAA, GDPR and the EU AI Act.

Data Workers doesn't make you compliant; your controls, people and assessors do. It supplies controls and evidence wherever agents touch data. Not legal advice.

The alternatives finance data teams weigh

Build it yourselves. A strong team can wire a coding agent to MCP servers for the warehouse and dbt. The work is everything around it: routing each adjustment to the right owner, blast radius, rollback, receipts, and current context about every other system.

Close management, reconciliation and planning software. These tools run the checklist, match transactions inside the ledger and hold the plan. They depend on the data feeding them. Data Workers keeps that data right underneath them, traces a wrong number to its cause and leaves the receipt. See how this works beside Lightup for reconciliation gaps and Alteryx for analyst-built close workflows.

Platform-native agents. The warehouse vendors ship agents that work well inside their own platform. Finance work crosses the ERP, the orchestrator, the warehouse and BI, and Data Workers works across all of them. If your SAP BW estate is moving, read the move to Business Data Cloud.

In this space specifically. Spreadsheets and analyst-owned macros are the incumbent. Agents replace the repetitive tie-out inside them and leave the judgment, the entry and the sign-off with finance.

The case for your CTO

What this replaces. The last-week rebuild of reconciliations, accrual checks and flux in spreadsheets, hand-remapped ERP extracts and weeks of evidence gathering.

What your team gets back. A finance data team that ships forecasting and spend products instead of re-running the tie-out and answering "which number is right".

Integration effort. Connecting is configuration, not a migration. The agents attach over MCP to the warehouse, orchestrator, dbt project and ERP extracts you already run, under the roles you already govern, inside your own infrastructure. Your engineers can read every tool the agents call in the open-source core.

Risk and control. Autonomy is set per domain. Everything starts at L1, observing only; reversible work moves up only when the receipts justify it; journal entries, adjustments and published numbers stay with a named approver; and one org-wide stop halts all autonomous work.

Why now. Finance is being asked to close faster and to put AI assistants in front of the ledger. Both multiply the cost of a number that does not tie.

The first win. Daily tie-out and the close checklist for one entity. The pilot below lays out the scope, what you see each week and the cost.

The climb: from assisted to autonomous to agentic

Our thesis is that the data platform climbs the way analytics did, in stages, and that the hard part of data work was never knowing what to do but doing it. For finance data teams, the climb looks like this:

• •Assisted. Agents work alongside your team. They read the whole stack, show what needs doing and propose every fix with a receipt; journal entries, adjustments and published numbers always go to a named approver.
• •Autonomous, under your governance. Routine work runs on its own: subledger and bank tie-outs run daily, ERP changes are remapped before reports publish and evidence is captured as work happens. Your team governs the agents instead of doing the upkeep.
• •The agentic enterprise. A finance data team that ships forecasting and spend products instead of rebuilding the tie-out. People set direction, and the platform carries it out.

You choose the altitude, every step is visible and reversible, and the pilot below is the first rung.

The pilot: how finance data teams start

The pilot is how your team proves the value on its own data before committing.

• •What we connect. Your ERP extracts, subledgers and bank files, Snowflake or Databricks, dbt, Airflow and the BI tools finance reads, over MCP, inside your infrastructure. Nothing migrates.
• •Scope. Daily tie-out and the close checklist for one entity.
• •First week. Agents run at L1 across the scoped entity. They map every pipeline, definition and lineage path and show the fixes they would have made, with receipts, so your team sees the value before anything changes.
• •By week two. Daily subledger and bank tie-outs and ERP change remapping start running on reversible work. Adjustments, accruals and published numbers stay at L2 with a named approver.
• •At day 30. We review the impact metrics against your baseline:

• •Subledger tie-out: from about a week to 15-20 min
• •Flux explained: from about 3 days to about an hour
• •Audit evidence package: from about 2 weeks to 4 h
• •the share of catalog and docs upkeep closed autonomously, targeting 88% as the deployment matures

• •What you decide. Whether to expand to the next entity or the next process. The pilot fee is credited in full against the first year.
• •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.

The pilot is the start of a longer curve:

By month 12, more than 40% of agent actions run fully autonomously and manual work falls below 10%, while entries and published numbers stay with a named approver.

FAQ

Does it work with SAP, Oracle, NetSuite and Workday Financials? Yes, through the extracts, replicas or warehouse tables you already load; the agents attach to the warehouse and orchestrator, not inside the ERP.

Will agents post journal entries? No. Entries and adjustments are prepared as proposals with the supporting records, and a named person posts them in the ERP through your existing approval workflow.

Can it help with SOX evidence? Yes. Actions, approvals and changes are recorded in a tamper-evident audit trail, and lineage and access evidence can be exported on request. Your controls and assessors decide what satisfies the requirement.

Where do the agents run? In your infrastructure, with your credentials and model key. The hosted Conductor sees workflow metadata only.

Do we have to migrate anything? No. Your ERP, warehouse, dbt project, orchestrator, close tools and BI stay where they are.

Where do the other finance and insurance data teams fit? See the group page for finance, insurance and investment data teams.

Sources

• •Data Workers pricing: https://dataworkers.io/pricing/
• •PCAOB, AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements: https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201
• •COSO, Internal Control framework guidance: https://www.coso.org/guidance-on-ic