Month-end close at most companies runs on tribal knowledge. The controller knows which journal entries to post in which order. The senior accountant knows which reconciliation to run before the ERP cutoff. The finance analyst knows which spreadsheet to pull from which shared drive and which cells to refresh manually. This knowledge isn’t documented anywhere. It lives in the heads of the people who have run close enough times to have internalized the sequence.
This works until someone is out sick, until a team member leaves, or until a new system is added to the close sequence and the informal mental model breaks. Then close takes longer than planned, exceptions don’t get caught, and the controller spends the last three days of the month in crisis mode rather than in review.
The alternative is treating close as a workflow rather than a project — a defined sequence of steps, with dependencies, owners, completion criteria, and a record of what ran.
The Difference Between a Checklist and a Workflow
A checklist is better than nothing. It documents the steps. But a checklist doesn’t enforce order. It doesn’t gate step 12 on the completion of step 7. It doesn’t timestamp completions or alert anyone when a step is late. And it requires someone to manually update it every month.
A workflow enforces sequence. When the bank reconciliation step is marked complete, the workflow automatically makes the accrual posting step available to run. When an accrual is posted, the workflow records which ledger it touched, who approved it, and what the supporting documentation was. When a step is overdue, the workflow alerts the owner and the controller.
The difference in outcomes is significant. A checklist-managed close depends on every participant remembering to check the list. A workflow-managed close fails loudly when a step is missed — and it fails before the deadline, not after.
Mapping Your Close to a Dependency Graph
The first step in converting a close process to a workflow is mapping it as a dependency graph. Every step has:
- Prerequisites — steps that must complete before this step can begin
- Inputs — specific data or reports that this step consumes
- Owner — the role responsible for execution
- Completion criteria — what evidence confirms the step is done
Here’s an abbreviated dependency map for a typical sub-close:
Bank statement received (external)
└── Bank reconciliation (AP/AR analyst)
└── Unreconciled items reviewed (controller)
└── Journal entries posted (senior accountant)
└── Ledger tie-out (controller)
└── Period locked in ERP (controller)Each arrow represents a gate: the downstream step cannot start until the upstream step is confirmed complete, with supporting evidence attached. The controller’s review cannot begin until the reconciliation is done. The period cannot lock until the ledger ties out.
Mapping this graph takes time the first time. Most finance teams discover, mid-exercise, that their informal close sequence has implicit dependencies they hadn’t articulated — and that some steps are running in parallel that should be sequential, or waiting for each other when they could run in parallel.
What Stays Manual, What Becomes Automated
Not every close step should be automated. The goal is to automate the execution steps and keep humans in the review and judgment roles.
| Step type | Approach |
|---|---|
| Data extraction (bank statements, ERP exports) | Automated on schedule |
| Reconciliation against defined criteria | Automated; exceptions surfaced for review |
| Journal entry posting within policy limits | Automated with audit log |
| Journal entry approval above threshold | Manual, with defined approval chain |
| Accrual calculation from defined inputs | Automated; calculation documented |
| Subjective estimates (warranty reserves, contingencies) | Manual, with supporting documentation |
| Ledger review and sign-off | Manual — this is the controller’s role |
| ERP period lock | Automated after sign-off recorded |
The boundary isn’t arbitrary. Steps that produce the same output from the same inputs every month can be automated and should be — the automation is faster and produces an identical audit trail. Steps that require professional judgment stay with the human, and the workflow structures when that judgment is needed and records what decision was made.
The Close Calendar as a Deliverable
When close is defined as a workflow, the close calendar becomes a real deliverable rather than a loose target.
A workflow-based close has a defined critical path — the longest chain of dependent steps that determines the minimum close duration. If you know that bank reconciliation requires one business day and that three steps depend on it, you know the earliest date those steps can complete. From that, you can calculate the earliest possible close date given your step inventory.
The question “when can we close?” should have a calculable answer, not an experiential one. If you don’t know the answer until the controller calls it, your close is still a project, not a workflow.
This matters practically at faster-growing companies where close speed affects financial reporting timelines, board preparation, and in the case of public companies or pre-IPO companies, external reporting obligations. Reducing close time by five business days is a compounding benefit: it extends the time available for analysis, reduces the error rate from rushed work, and lowers the cost of the close itself.
Building the Audit Record
A workflow-managed close produces a richer audit record than a checklist-managed close — not because it’s more complex, but because the record is created systematically rather than retrospectively.
For each close step, the record includes:
- The step name and the workflow version that defined it
- Who executed it and when
- What inputs were consumed (specific files, report versions, ERP run IDs)
- What output was produced (journal entry IDs, reconciliation reports, sign-off records)
- Whether any exceptions were surfaced and how they were resolved
This record is immediately useful in the next close — you know exactly what ran last month and can compare. It’s also useful for auditors: instead of reconstructing close activity from emails and spreadsheet versions, you hand them a structured record of every action taken in every close for the period under review.
Starting Without Overhauling Your Stack
You don’t need to replace your ERP, your close management tool, or your accounting system to start treating close as a workflow. Start with documentation.
Write out every close step. Map the dependencies. Assign an owner to each step. Define the completion criterion. Then run the next close against that document — not as a checklist you can ignore, but as a specification you verify against. When a step completes, record it with a timestamp and attach the supporting evidence.
This is a manual workflow. It’s also better than what most teams have. And it produces the dependency map and step inventory you’d need to automate the execution steps once you’re ready.
The transition from manual workflow to automated workflow is straightforward when the workflow is documented. Automation doesn’t change the logic — it runs the documented process without requiring humans to remember what the documented process says. That’s the right division of labor for a finance team: define the process, verify the outputs, own the exceptions.