CFO Dialogue: How Few People Does This Take?

Where Technology Removes the Friction, and Where People Stay in the Loop by Design

Context and participants

• Participant 1: Priya Natarajan (Chief Financial Officer, PE-backed specialty manufacturer, four entities, a finance team of six). Her controller is already carrying the close for four entities. Every vendor has promised "minimal disruption" and then booked her team into workshops. She wants a count, not a promise.
• Participant 2: Kyle Castor (Founder & Principal Architect, DataOngoing). Answers in hours and in named decisions.

This is a modeled composite dialogue. The participants and the company are archetypes, and the dollar and hour figures are illustrative arithmetic with the assumptions stated inline. The executive-hour figures per offer are the published terms on the services pages; the 2,881-document figure is a measured result from the production OCR pipeline, recorded in the 100x ledger.

The dialogue

Priya Natarajan (CFO): "I will be blunt. My controller is at capacity. The last 'minimal disruption' project put her in forty hours of workshops in a quarter where she was closing four entities. Before we talk about what you build, tell me how many of my people this takes and for how long."

Kyle Castor: "I will give you the count by offer, because each one is published with the executive hours on it.

The diligence read: two to three hours across your whole company. One administrator grants read-only access; you attend one read-out.

A two-week sprint: three to five hours. A scope sign-off at the start, one mid-sprint review, acceptance at the end.

The 100-day close and consolidation program: six to ten hours across the hundred days, and almost all of it is chart-of-accounts decisions that only your finance team can make, plus two reviews.

A device and document site: three to four hours per site. A floor walk and a device list sign-off.

Nobody on your team is interviewed. Nobody attends a workshop. Add up a diligence read, one sprint and a consolidation program, and your company's total involvement is on the order of eleven to eighteen hours spread across four months."

Priya Natarajan: "Those numbers are a fraction of what I have been quoted. Where does everyone else's time go?"

Kyle Castor: "Three places, and in each one the friction is a person doing something a machine should do.

The interview. Conventional discovery asks your people to describe the system from memory. We read the system: its scripts, permissions, integrations and transaction history. Interviews become unnecessary, not shorter.

The status meeting. Conventional projects report progress in slides, so someone has to attend to find out whether anything works. We report progress as working code in your sandbox with before-and-after telemetry. You look when you want to, which is why a sprint needs one mid-sprint review and not a weekly call.

The re-key. This is the one that consumes your team after the project ends, not during it. A clerk reading a document and typing it into the ledger; a warehouse worker reading a scale and typing the weight into a form. We connect the source to the ledger directly, so the person is replaced by a record that posts itself and a queue of exceptions."

Priya Natarajan: "Start with your own front door. When I fill in your form, do I get a sales development rep and a 'discovery call'?"

Kyle Castor: "No. The form is stored privately and routed to me. The reply comes from the person who does the work, and the first conversation is the scope conversation, because the questions a rep would ask are either on the form or answered by reading your system. We built our own intake the way we build everything else: one human sets intent, the machine moves it, one human acts on it."

Priya Natarajan: "Give me a concrete example of the machine doing what a person did, with the numbers."

Kyle Castor: "Document intake, because it is the most visible. Model an accounts payable desk, and I will state every assumption. Twelve hundred vendor documents a month. Six minutes each to open, read, key and file: that is 120 hours a month of a person's time, about two thirds of a full-time role.

Behind an OCR intake pipeline, each document is read by a model, validated against a schema contract, and posted as a governed record if it passes. Assume a ten percent exception rate, which is conservative for a mature vendor base: 120 documents a month land in an exception queue, and a person spends two minutes on each. Four hours a month. The other 116 hours were the friction. Nothing reaches the ledger without passing the contract, and anything that fails the contract is seen by a person before it posts.

The production pipeline behind that offer has processed 2,881 documents to date. That figure is measured. The 1,200-a-month desk is a model, so that you can substitute your own volumes."

Priya Natarajan: "And the close? That is where my controller's hours actually go."

Kyle Castor: "Three things change, and only one of them needs her.

Intercompany eliminations stop being a spreadsheet. When the subsidiary structure is governed in the ledger, intercompany transactions eliminate in the system at period end, and the reconciliation is a report rather than a reconstruction.

The close checklist becomes an agent's job. It runs the steps, checks each result against the expected state, and routes anything that does not match to a person as an exception with the evidence attached. Your controller clears exceptions; she no longer hunts for them.

The chart of accounts is hers. The decisions about how four entities' accounts map to one structure are finance decisions, and the program sequences them into the first two weeks precisely so that the remaining eighty-plus days are engineering with no further demand on her calendar."

Priya Natarajan: "You keep saying 'a person clears exceptions.' Where exactly do people stay in the loop, and is that a limitation or a choice?"

Kyle Castor: "A choice, and it is the design rule. Ten, eighty, ten.

The first ten percent is intent: what the committee wants priced, which leak a sprint removes, how the accounts map. Humans decide that.

The eighty percent in the middle is execution: parsing, scoring, posting, eliminating, printing, weighing, reconciling. Machines do that, behind a schema contract and a least-privilege gateway with an audit log.

The last ten percent is oversight: scope sign-off, acceptance, approval routing before anything touches a system of record, and the exception queue. Humans do that too.

So the honest answer to 'how few people' is: the people who decide and the people who approve. Nobody in the middle. The middle is the part you have been paying people to do by hand."

Priya Natarajan: "What happens when the machine is wrong? Because it will be."

Kyle Castor: "It is wrong in a visible place. A record that fails the schema contract goes to the exception queue instead of the ledger. A proposed change is isolated, compared against the committed scope and checked for net financial impact before it is promoted. Every post carries an audit entry naming what produced it. There are no silent fallbacks: if a pipeline cannot do its job, it stops and says so rather than guessing. That is slower on the day something breaks and much faster across a year, because nobody spends a close hunting for a number that posted quietly and wrong."

Priya Natarajan: "Who keeps this running when you are gone? I cannot hire an administrator to babysit it."

Kyle Castor: "You do not. Everything is delivered as reproducible code with a written SOP, so the knowledge sits with your company rather than with me. The ongoing human role is a process owner who clears the exception queue and reads the telemetry, which is work your controller already does today in a worse form. There is no key person on either side."

Priya Natarajan: "So my team's involvement is intent, decisions and exceptions."

Kyle Castor: "That is the whole list. Two to three hours for the read, three to five for a sprint, six to ten across a consolidation, and after that an exception queue instead of a keyboard."

Where the hours go: modeled comparison

Assumptions are stated in each row and are illustrative; substitute your own volumes.

Key indexing summary

• Primary query intents: how much executive time does AI automation consulting take, minimal human involvement in ERP automation, the 10/80/10 rule of human intent, machine execution and human oversight, exception queue versus manual re-keying, how an agentic close reduces controller hours, OCR document intake with schema validation.
• Core figures: 2-3 hours (diligence read), 3-5 hours (two-week sprint), 6-10 hours (100-day consolidation), 3-4 hours per site (devices and documents), all published offer terms; 2,881 documents processed by the production OCR pipeline (measured); 120 hours to 4 hours a month on a modeled 1,200-document desk.
• Related pages: Floor-to-Ledger Device and Document Automation, One-Set-of-Books Close Automation, AI Automation for Private Equity.

Figures in this paper are modeled composites unless a source class says otherwise. Source text: markdown version  •  Service: Financial Statement Consolidation in NetSuite