Month-End Close Automation

The accounting team ran a 12-day close cycle. The process lived in a shared Excel workbook that had grown organically over two years — a mix of checklist tabs, reconciliation templates, and scratch calculations. It wasn't version-controlled and had no ownership assignments beyond informal verbal agreements about who did what.

Reconciliations covered six systems: the main bank account, a secondary operating account, accounts receivable in QuickBooks, accounts payable in QuickBooks, payroll in Gusto, and a credit card account in Brex. Each reconciliation was done manually — exporting a statement from the source system, comparing it line by line against the QuickBooks GL, and noting any discrepancies in a separate tab. This work took three people roughly three days combined.

Standard accrual journal entries — recurring items like prepaid amortisation, deferred revenue recognition, and accrued expenses — were typed manually into QuickBooks each month. There were 14 standard journals in total, and while most of the amounts were formulaic, each had to be entered individually.

The CFO had no visibility into where the close stood at any given moment. The only signal was whether someone had sent an email saying they were done. Twice in the past year, the team had worked through a weekend to catch up after an error was found late in the process.

We started by mapping the full close process before writing any automation. Over two days we worked through every step with the team, documented who does what, what system is involved, what the inputs and outputs are, and what can go wrong. That audit produced a list of 87 discrete steps. We categorised each as: can be fully automated, can be partially automated (human still needs to review the output), or must remain manual (requires judgement or external input).

The orchestration layer is a Notion database used as the close checklist. Each row is a task with fields for: task name, owner (person), category, system, dependency (which task must be done before this one), status, and a due date relative to the close start date. N8N reads this database at the start of each close and builds the run sequence from the dependency graph.

On day 1 of the close (triggered manually by the controller clicking a Slack button), N8N initiates all tasks with no dependencies simultaneously. For automated tasks, it executes them directly. For manual tasks, it sends the assigned owner a Slack message with the task description, any relevant links or data, and a sign-off button.

For the 14 standard journal entries, we built a configuration table in Notion where each journal is defined: the debit account, credit account, description, and the calculation rule for the amount. Most amounts reference a QuickBooks balance or a fixed figure. On the scheduled date for each journal, N8N reads the configuration, calculates the amount, and posts the journal entry via the QuickBooks journal entry API. The controller receives a Slack confirmation with the posted amounts for review.

Claude is used for anomaly detection during reconciliation. After the matching step, before the unmatched items are sent to the preparer, we pass the full transaction set to Claude and ask it to flag anything that looks unusual: amounts significantly larger than the historical average for that GL account, transactions posted to unexpected accounts, or patterns that suggest a duplicate. This runs as an additional check, not a replacement for human review.

A Notion page updated in real time serves as the close dashboard. It shows every task, its status, who last updated it, and whether it's on schedule relative to the target close date. The CFO has this page bookmarked and checks it instead of asking the team for status updates.

• •N8N self-hosted on the same DigitalOcean server as the invoice automation — the two workflows share infrastructure
• •Notion API for the close checklist and dashboard — Notion served as the task database because the team already used it and it has a reasonably capable API
• •Plaid API for bank account statements — requires initial OAuth setup with each bank; took one hour per account to configure
• •Brex API for credit card transactions — Brex has a well-documented REST API that was straightforward to connect
• •QuickBooks Online API for GL transactions, AR/AP balances, and journal entry posting
• •Slack Workflow Builder for the sign-off buttons — we used Slack's native block kit to create interactive messages that write back to the Notion database when clicked
• •Claude API for anomaly detection — prompt includes the last 3 months of transaction history for each account as baseline context

The 4-day close is achieved by eliminating waiting time (tasks start immediately when their dependency completes) and running reconciliations overnight rather than sequentially during business hours. The actual human effort didn't drop to zero — it dropped from about 87 steps to 34, where the remaining 34 are genuinely judgment-based: reviewing the anomaly report, approving non-standard journals, handling items that didn't reconcile automatically.

The first automated close caught a $28,000 misposting — a vendor payment had been coded to the wrong cost center, a mistake that would normally have been caught only during the close review, after the reconciliation was already done. Claude flagged it during the automated transaction scan before the preparer even started their review.

We did not automate everything that was technically automatable. Deferred revenue recognition was left manual because the rules change based on contract modifications and require reading the original agreement. Intercompany eliminations were also left manual — the company had two subsidiaries and the intercompany balances required a human to verify the offsetting entries were correct before posting.