Finance leaders are being asked to “implement AI” when what the team usually needs is more specific: fewer manual hand-offs, faster close, cleaner reconciliations, better exception visibility or management reporting that arrives before the decision is already made.

That distinction matters. A model is not a finance transformation strategy. The operating model around the model — ownership, data access, review, escalation and measurement — is what determines whether automation survives contact with month-end.

This is the 90-day sequence I would use with a CFO, controller or finance-operations leader who wants a useful first release without weakening financial control.

The decision rule: automate a constraint, not a department

“Automate finance” is too broad to fund responsibly. Start with a constraint the team already feels:

  • reconciliations remain open beyond the review date;
  • invoice or expense data is re-keyed across systems;
  • month-end commentary is assembled manually from several reports;
  • exceptions are found late because nobody owns the queue;
  • the management pack is accurate but arrives too slowly to change action.

Write the constraint as a sentence with a number: “We spend 80 review hours each month clearing exceptions,” or “The close pack is ready on day 12, but the business needs it on day 7.” The number does not need to be perfect. It needs to be good enough to compare the current process with the proposed one.

Days 1–15: baseline the work and protect the control environment

The first fortnight is not a vendor selection exercise. It is process discovery. Sit with the people who perform the work and capture:

  • the trigger and expected output;
  • systems of record and data hand-offs;
  • volumes, timing and recurring exceptions;
  • approval thresholds and segregation-of-duties points;
  • the person accountable for clearing an exception;
  • the evidence a reviewer or auditor would expect to see.

Classify every field the workflow touches. Client identity, unpublished financial information, payroll, bank data and draft advice should not be pasted into an unapproved consumer tool. Decide where processing may happen, how long inputs and outputs are retained, and what gets logged.

Then write the “human gate” in plain English. For example: “The system may suggest a match; the finance manager approves any match above the threshold and every item in the low-confidence queue.” If a team cannot explain the gate, the workflow is not ready.

Days 16–30: choose the narrowest useful release

Score candidate workflows on four dimensions:

  1. Business impact: will it reduce cycle time, rework, leakage or review effort?
  2. Data readiness: are the inputs stable, accessible and sufficiently structured?
  3. Control risk: what could go wrong, and can a person detect and correct it?
  4. Adoption likelihood: will the team use it inside the existing cadence?

The best first release is often less glamorous than a chatbot: suggested bank matches, invoice-field extraction, an exception queue, variance commentary drafts or a controlled management-reporting assistant. These workflows have a visible before-and-after and can keep final judgement with the finance team.

Do not select a use case just because a vendor demo made it look easy. Select it because the process owner can explain the current pain, the target state and the review rule.

Days 31–60: build, test and instrument

Build the smallest version that can run with real, representative work. Keep a test set that includes ordinary cases and awkward cases: missing fields, duplicate invoices, unusual vendors, period-end pressure and records that should be escalated.

Track at least five measures:

  • time from input to usable output;
  • percentage routed without manual re-keying;
  • exception rate and age of the exception queue;
  • review hours and rework;
  • adoption by the people who actually perform the process.

Keep a decision log. Record the version of the workflow, the data assumptions, the test results, the known failure modes and the changes made after review. This is not bureaucracy for its own sake. It makes the release explainable when the process changes or a reviewer asks why a result was accepted.

Days 61–90: embed the workflow and decide whether to scale

By this point the question is not “Is the model impressive?” It is “Is the process measurably better without creating a control problem?”

Run a review with the owner, finance leadership and the relevant control stakeholders. Compare the baseline with the live workflow. Look for hidden costs: additional review time, vendor lock-in, manual cleanup, data-retention concerns or a queue that nobody wants to own.

Scale only if three conditions are true:

  • the process owner can explain the workflow and exception route;
  • the metric improved without unacceptable control degradation;
  • the team uses the workflow consistently without heroic supervision.

If one condition fails, improve the process before expanding the scope. A disciplined “not yet” is a better finance decision than a second pilot built on an unresolved first one.

What should remain human?

Automation can prepare, classify, reconcile, route and draft. It should not quietly assume accountability for material judgement. Keep people responsible for approval, unusual estimates, interpretation of ambiguous evidence, fraud indicators, client advice and decisions where the consequence is difficult to reverse.

This is especially important for finance teams because accuracy is not the only objective. Auditability, confidentiality, segregation of duties and the ability to reconstruct what happened matter just as much. The audit working-papers guide applies the same principle to documentation: the tool may assist, but the engagement team remains accountable for the work and review.

Build or buy?

Buy the commodity layer when a credible product already handles the workflow, permissions and audit trail you need. Build where your process, data or control design is genuinely differentiating. The decision should follow the baseline, not precede it.

For the decision framework, see Build vs Buy: A Practical Framework for AI Tooling. For a broader view of the finance function as an AI starting point, read The Finance Function Is AI’s Highest-ROI Starting Point.

A one-page 90-day brief

Before starting, write this on one page:

  • Constraint: the process problem in one sentence.
  • Owner: one person accountable for the result.
  • Baseline: the current time, volume, error or exception measure.
  • Release: the smallest useful workflow to ship.
  • Human gate: what the system may suggest and what a person must approve.
  • Review rhythm: when the team checks quality, exceptions and adoption.
  • Scale decision: the evidence required before adding a second workflow.

If the brief fits on one page, the team can usually explain it. If it does not, the scope is probably still a strategy deck rather than an implementation plan.

Sources

Educational commentary from implementation work — not personalised financial, tax, legal or investment advice. Verify vendor pricing, privacy terms and your own policies before you buy.