Vision
The close is not a process
Why month-end close is a judgment-intensive reckoning, not a task list, and what that means for the software that touches it.
Every project management tool wants to turn the close into a checklist. Assign tasks, set due dates, track completion. The close as a manufacturing line: input raw numbers, output signed financials.
This model is wrong. And the software it produces is wrong in the same way.
What a process is
A process is a sequence of steps that reliably produces the same output from the same input. It can be templated. It can be delegated to someone with less context. It benefits from speed. The path of least resistance is the right path.
Month-end close is not this.
What the close actually is
The close is a reckoning. It asks: what actually happened this period, and can we defend that account of events to the board, the auditors, and the regulator?
That question is not answerable from a checklist. It requires judgment at every non-trivial step:
- Is this accrual still correct given what we know today that we did not know when we opened the estimate?
- Is the IC pair off because of a timing difference or because something actually went wrong?
- Is this variance explainable or does it require an adjustment?
- Is this one-time or recurring?
No template anticipates these questions. The controller who asks them well is not executing a process — they are exercising judgment on behalf of the entity. They are doing work that is not compressible into a task.
Why the last 20% takes 80% of the time
This is the pattern every finance leader knows and no one designs for.
The templated steps — pulling the TB, populating the IC schedules, running the standard accruals, formatting the pack — these go fast. They can be accelerated. Yig drafts them.
The last 20% is the edge cases. The one-time settlement. The entity that reorganised mid-period. The FX rate that moved 8% in the last week and invalidates three months of forward estimates. The intercompany balance that won’t reconcile because one entity accrued and the other has not yet received.
Edge cases are not bugs in the process. They are the work.
Automation that hides edge cases does not save time. It moves the time to the audit response. It converts ten hours of close time into forty hours of explaining to the auditor why the numbers moved in a way no one flagged.
The implication for software
Software that treats the close as a process optimises for speed through the templated steps. That optimisation is real and worth capturing.
But software that stops there — that hands you a completed output and asks you to trust it — has made a bet that the edge cases won’t show up this cycle. That bet fails in real months.
The right frame is this: drafting is automatable; judgment is not.
This is not a philosophical claim about AI capability. It is a structural fact about what auditors require and what controllers are paid to provide. The controller who sees the draft and reviews it line by line is performing a function that cannot be removed from the close without removing the controller. That function is the point.
Yig’s job is to get the draft to the controller faster, and then get out of the way.
What this rules out
It rules out “press button → close ships.” Not because the button is technically impossible, but because the output of that button is not a close. It is a number without a reviewer behind it. Auditors do not sign numbers without reviewers behind them. Finance leaders do not stake their professional reputation on outputs they did not review.
It rules out software that makes the judgment calls for you and surfaces only the answer. Every hidden judgment call is a liability the finance team inherits without knowing it.
It rules out treating the close as a manufacturing problem. Manufacturing optimises for throughput. The close optimises for correctness, defensibility, and trust — three things that are not improved by speed alone.
The bet
We are building software for the judgment-intensive 20%, not just the templated 80%.
The templated 80% is how we earn the right to be in the room. The judgment-intensive 20% is where the product actually lives — or does not.
That is a harder product to build. It takes longer to prove. The ROI is less legible in a demo. But it is the product finance teams will use at 11pm on day six of a hard close, and it is the only product that survives an audit.