How to build financial close automation

What matters here

• Model dependencies, not a checklist. A percentage complete hides which task is actually blocking the close.
• Pull source data before it is asked for. Most close delay is waiting for a file somebody has to be chased for.
• Show the critical path. Two tasks usually decide the close date and eighty do not.
• Reconcile continuously through the month. A break found on day two of close was there for three weeks.
• Measure days to close and where they went, not tasks completed.

Who this is for

You run financial systems or the close. Nine days, a spreadsheet of tasks, and a daily stand-up to work out what is blocking what.

How it works in practice

What has to happen between period end and the books being closed.

1. 1

   Tasks are generated from a template per entity and period

   With owners, dependencies and estimated durations, not a copied spreadsheet.

2. 2

   Source data is pulled before it is requested

   Bank statements, subledger extracts, payroll files, and anything from a system instead of a person.

3. 3

   Dependencies decide the order, not the list

   A task is available when its predecessors are done, and unavailable tasks are hidden rather than shown as pending.

4. 4

   The critical path is computed and published

   So the daily question of what is blocking us is a screen instead of a meeting.

5. 5

   Reconciliations that ran all month are already done

   Only the exceptions arrive at close.

6. 6

   Time is measured per task and per path

   So next period improves the thing that actually cost days.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Set up and model the close as a graph

   A checklist cannot show you what is blocking.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are NetSuite, or whatever we
   run in those seats.
   
   Build the close as a dependency graph rather than a checklist. Each task
   carries: name, owner, entity, estimated duration, predecessors, and
   whether it is automated or manual.
   
   Generate the tasks per entity per period from a template instead of 
   copying last month's spreadsheet.
   
   The dependencies are the point. A flat list of ninety tasks at sixty
   percent complete tells nobody whether close is on track, because the two
   tasks blocking everything look exactly like the eighty that block
   nothing.

   Getting the durations roughly right matters less than getting the dependencies right. The graph shape drives everything.

2. 2

   Pull the data before anybody asks

   Most close delay is waiting on something a system could have sent.

   Headless skills build-workflow

   Copy

   Use build-workflow. Before close opens, fetch everything that comes from
   a system rather than a person:
   
     Bank statements for every account
     Subledger extracts: AR, AP, fixed assets, inventory
     Payroll files for the period
     Expense and card feeds
     Revenue data from the billing system
     FX rates for the close date, from the agreed source
   
   Have all of it staged and validated before day one. Chasing a file is the
   most common single reason a close task starts late, and every one of
   these can be fetched instead of requested.
   
   Validate on arrival: expected file, expected period, expected format. A
   bank statement for the wrong month is better caught on arrival than
   during a reconciliation.

3. 3

   Compute the critical path and publish it

   Two tasks decide the close date and eighty do not.

   Copy

   Compute the critical path through the dependency graph and republish it
   as tasks complete.
   
   Show, on one screen: which tasks are on the critical path right now, who
   owns each, how long each has been open, and the projected close date if
   nothing changes.
   
   Hide tasks that are not yet available. Showing somebody a task they
   cannot start is noise, and a list where most items are blocked trains
   people to ignore the list.
   
   That screen replaces the daily stand-up question. What is blocking us
   should be a glance instead of a meeting, and the projected date moving
   should be an alert, not a discovery.

4. 4

   Reconcile all month, not at close

   A break found on day two of close was there for three weeks.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then run reconciliations continuously through the
   period, not as close tasks:
   
     Bank to ledger, daily
     Subledger to general ledger, daily
     Intercompany balances, weekly, because those take longest to resolve
     and involve two teams
     Suspense and clearing accounts, weekly
   
   Alert on a break when it appears, not when close begins. A break found on
   day two of close has been there for three weeks and the person who caused
   it has forgotten.
   
   Then close inherits a list of known exceptions instead of discovering
   them, and the reconciliation tasks become a review rather than an
   investigation.

5. 5

   Measure where the days actually went

   Tasks completed is a comfort metric.

   Copy

   Record start and finish per task, and which tasks were on the critical
   path each period.
   
   Report: days to close, trended; time on the critical path by task; tasks
   that were late and why; how often the same task is the blocker; and time
   spent waiting for data against time spent doing work.
   
   That last split is the one that tells you what to automate next. If half
   the close is waiting, the fix is upstream instead of in the close
   itself.
   
   Do not report tasks completed or percentage complete. Both rise steadily
   regardless of whether the close is on track.

6. 6

   Validate, then hand the template to finance

   Because the close changes with every entity and system.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production. Run it alongside the existing close for one period,
   computing the critical path without anybody relying on it, and compare
   against what actually blocked.
   
   Then open the same workflow in Tray Build so the finance systems team can
   maintain the task template, the dependencies and the data pulls in the
   visual canvas.

What it connects to

Close pulls from every financial system and has to tell people what is blocking.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides