AI workflow around the month-end close — design discipline for finance teams

An AI workflow around the month-end close is a predefined chain of steps where each step is executed by software, an LLM, or a human — deterministic in structure, with probabilistic room where the model takes over. For finance teams, the difference between workable and chaos sits in four design choices: trigger, engine-per-step, HITL cut points, and iterative rollout.

An AI workflow for the month-end close isn't a prompt and isn't an agent. It's a predefined chain of steps where each step is executed by software, an LLM, or a human, and where the output of one step becomes the input of the next. Deterministic in structure, with probabilistic room where the model takes over.

The mistake finance teams make most often: start building straight away in n8n, Zapier, or a custom agent platform. Drag nodes, tune prompts, wire the Exact connector. Two days later there's something that works for one test case and breaks on the second. Workflow design on paper — a simple flowchart — costs an hour and saves days of rebuilding.

For the anatomy of what AI actually does in the close — which steps, which time savings, which audit requirements — see AI in the month-end close. This piece is about the design discipline that comes first.

Why design on paper first

• Everyone on the same reality. The finance team only reaches a shared definition of steps, responsibilities, and data flow when they draw it.
• Fix the process before automating. Mapping exposes gaps in the close cycle that stay invisible in a loose description — manual Excel files between steps, missing cost-center tags, single-person knowledge on a specific posting.
• Separate automatable from non-automatable. A good diagram shows which step an LLM can handle (variance commentary), which requires pure tooling (data pull from Exact), and which needs a human (judgment on provisions).
• Blueprint for the build phase. With a clear design you build the workflow once, not three times.

The five steps of workflow design for the close

1. Foundation — trigger, action, output

Start with the outside. What kicks off the close, what happens broadly, what is the end result?

For a typical month-end close:

• Trigger: business day 1 of the new month, or: all bank statements have been imported.
• Action: bank reconciliation, intercompany reconciliation, period corrections, VAT check, variance analysis, board-pack creation.
• Output: published board pack, closed period in Exact, VAT reconciliation done, audit trail complete.

These three together are the foundation. As long as they aren't fixed, every step below is built on quicksand.

2. Break it down — activities per phase

The action bundle from step 1 is too coarse. Slice it into discrete activities you can automate or control separately:

1. Pull and classify bank transactions.
2. Generate match proposals against open invoices.
3. Draft journal entries for unexplained items.
4. Approve postings.
5. Compare intercompany balances.
6. Period corrections (accruals, prepayments).
7. VAT reconciliation.
8. Variance analysis and commentary.
9. Board-pack compilation.
10. Distribution and archiving.

Every activity has one clear goal and one clear output. If an activity does two things at once (post + write variance commentary), cut further.

3. Engine per step — LLM, tool, or human?

For every activity, pick the right engine.

• LLM for language-intensive work: variance commentary, summarizing management reports, classifying transactions, draft mails.
• Tool or API for rules and data transformations: pull data from Exact, create records, map fields, send mails, close periods.
• Human for judgment, context, and accountability: assessing provisions, weighing materiality, validating board-pack content, filing VAT returns.

In the close example:

• Step 1 (data pull): tool/API.
• Step 2 (match proposals): LLM with code execution.
• Step 3 (draft postings): LLM with chart-of-accounts context.
• Step 4 (approval): human (HITL).
• Step 5 (intercompany): LLM with tool access to both tenants.
• Step 6 (corrections): human with LLM assistance.
• Step 7 (VAT): hybrid — LLM signals, human decides (see VAT reconciliation with AI).
• Step 8 (variance): LLM.
• Step 9 (board pack): LLM with file creation, then human.
• Step 10 (distribution): tool/API.

4. Oversight — where does the human enter the loop?

Not every LLM output may flow straight into the next system. Decide per activity whether the output flows directly or needs to pass a human first. The trade-off in finance: risk of error (financial, audit), impact (posting, external communication), and quality requirements.

Rule of thumb for the close: HITL on all postings, all VAT corrections, and all external communication (board pack, investor reporting). Autonomous where it concerns proposals and data aggregation. See Human in the loop in finance workflows for the broader logic.

Sometimes you split an activity to build HITL in cleanly — for example step 9 "board pack" into:

• 9a: AI fills the template with numbers and draft commentary.
• 9b: controller reviews and edits (HITL).
• 9c: publication via tool/API.

5. Build iteratively

Only after the design stands, open the automation platform. Build one step, test with real close data from a sandbox or test tenant, refine the prompt, and only then move to the next. Start small — one slice of the close, one trigger, one output — and expand once the base runs stably.

For finance specifically: build first on a test tenant. Touch production only after a step in test has run a full close cycle without intervention. That's not over-caution; that's baseline discipline for something that can land in the ledger.

Six building blocks in every platform

Whether you build in n8n, Zapier, Make, Power Automate, or a custom agent platform, every workflow is a combination of six node types:

• Trigger — when the workflow starts (calendar, mail, file drop, manual).
• Transform — shapes and cleans data (filters, mappings, normalizations).
• Logic — branches (if/switch), loops, parallel.
• Action — executes (accounting API call, mail, file creation).
• AI node — an LLM call with a prompt and optional tools.
• Feedback & logging — catches successes and failures, emits logs, makes status visible.

In the design, you translate each activity into a combination of these blocks. That makes the leap to implementation small.

Five design principles for finance workflows

1. Clear steps — one block, one goal, one output, one engine.
2. Modular blocks — repeatable tasks as sub-workflows (for example a "post-with-approval" module reused across five workflows).
3. AI augmentation where useful — LLM where language or reasoning is needed, tool where a rule suffices. Not AI for AI's sake.
4. Audit by design — log every step, every input, every decision, every human approval. Not as an afterthought — as a core requirement from day one.
5. Built-in safety — API keys in a secret store, role-based access, time-limited credentials, sandbox tenant for experiments. No production workflow without fail-safes.

A practical case

A controller at an 80-FTE scale-up wants to speed up the bank-reconciliation part of the close. Current situation: days 1-2 of the close go to manually matching 400-600 transactions against open invoices.

Workflow design:

• Trigger: business day 1, or bank statements imported.
• Activity 1 (tool): pull bank transactions from Exact.
• Activity 2 (tool): pull open invoices from Exact.
• Activity 3 (LLM with code execution): for every transaction, propose the most likely invoice number, with a confidence score.
• Activity 4 (logic): high-confidence transactions under €500 matched autonomously; the rest goes to a review queue.
• Activity 5 (human, HITL): AP clerk reviews the queue, accepts/corrects.
• Activity 6 (tool): approved matches written back to Exact.
• Output: bank reconciliation done, audit log per match.

Lead time for the controller: from 8 hours to 90 minutes of review. The AP clerk gets 200-300 matches in the queue instead of 600 in a spreadsheet. Fully auditable.