Enough fluency to be credible, and enough to ask a question that proves it.

How a finance org is shaped

You don't need an accountant's depth, but you do need to know who you'd be building for, because "Finance" is three quite different populations with different problems.

The three named projects map cleanly onto this: accruals is Controllership, headcount and consolidated spend are FP&A. Which tells you something useful — a transformation team's early wins are usually FP&A, because the control burden is lighter and the pain is more visible, while the durable wins are usually Controllership, because the close calendar is a hard constraint that everyone feels.

Accruals and the month-end close

What actually happens

Accrual accounting says an expense belongs in the period the value was consumed, not the period the invoice arrived. So at month-end, if a consultancy worked through March but bills in mid-April, Finance books an accrual in March for the estimated amount. The following month that accrual is reversed and the real invoice lands; the gap between the two is the true-up.

The accrual number comes from three places, in descending order of reliability:

1. Open purchase orders with a goods receipt but no invoice — the GR/IR position. This is systematic and mostly derivable. Good automation target.
2. Known contracts and run-rates — recurring vendors where last month is a decent predictor of this month. Modellable.
3. Manual estimates from cost-centre owners — someone in the business emails a number for work that has no PO. This is where the pain lives.

Why it's painful

The third category means Finance spends the first days of every close chasing several hundred non-finance people for estimates, in spreadsheets, against a calendar that cannot slip. Submissions come late, which compresses everything downstream. The estimates are often poor, which shows up as large true-ups the following month and eventually as an audit question. Nobody is measured on estimate quality, so nobody improves.

The metrics that matter

Where automation and AI genuinely help

• Auto-generate from GR/IR — deterministic, no model needed, and usually the biggest single chunk of value. Say this first; reaching for a model where rules will do is a tell.
• Estimate recurring spend from run-rate and seasonality — a modest statistical model beats a rushed human guess, and can be backtested against last year's actuals to prove it.
• Anomaly flagging on submissions — compare what someone submits against their own history and challenge the outliers, rather than reviewing all of them.
• Chase automation — unglamorous, and often the largest cycle-time win available.
• Narrative variance explanation — a language model drafting the "why did this move" commentary, reviewed by a human. Draft, never number of record.

Ask them: "What proportion of your accrual value comes from manual submissions today rather than from PO data — and does anyone currently measure accrual accuracy against the true-up?" That question tells them you know where the difficulty is.

The headcount dashboard

Why it is not a dashboard problem

Every organisation of size has attempted a single headcount view and most have failed twice. The reason is that "headcount" is not one number, and the systems that hold it were built for different purposes.

The five things that break it

• Definition drift. Filled vs. approved vs. requisitioned vs. contractor. Headcount (bodies) vs. FTE (fractions). Two teams reporting different numbers are usually both right under their own definition.
• Effective dating. Someone transfers cost centre on the 14th. Do they count against the old team or the new one this month? Both answers are defensible; only one can be in the dashboard.
• Hierarchy versioning. After a reorg, do you restate history under the new structure (as-is) or preserve what was true at the time (as-was)? Get this wrong and last year's numbers change every time the org does, which destroys trust faster than any bug.
• Two hierarchies. The manager hierarchy and the cost-centre hierarchy don't match, and Finance cares about one while HR cares about the other.
• In-flight people. Accepted-but-not-started, notice-period leavers, internal transfers counted twice.

Ask them: "When there's a reorg, does the dashboard need to restate history under the new structure or preserve what was true at the time?" Almost nobody outside the problem asks this, and it's the decision that determines the whole data model.

Consolidated estimated spend and forecasting

The shape of the problem

Three numbers get confused and shouldn't be: budget (what was approved, set once), forecast (what we now think will happen, updated), and actuals (what happened). Variance analysis is the comparison between them, and it's the core FP&A activity.

Estimated future spend arrives from a scattered set of places, each with different granularity, timing and reliability: the procurement pipeline, open POs and commitments, contract renewals, usage-based vendors (cloud is the usual offender), marketing commitments, and a long tail of team-level spreadsheets. Consolidating them is hard for unglamorous reasons — one input is by vendor, another by cost centre, another by project; one is calendar-month and another fiscal; the same commitment appears in two of them; and nothing carries a confidence signal, so a firm contracted renewal and someone's rough guess are added together as though they were the same kind of number.

How to talk about improving it

• A common taxonomy first. Category, cost centre, vendor, and time grain agreed before any consolidation.
• One named owner per input. Unowned inputs go stale silently.
• A confidence tier on every input — contracted, committed, planned, estimated. This single addition changes the conversation with leadership, because it lets you show a range rather than a false point estimate.
• Measure the error. Forecast accuracy by category and by owner, tracked over time. It converts a subjective argument into a trend, and it gives you the outcome metric a CFO will actually accept.

Ask them: "Is forecast error measured by category and by owner today, or only in aggregate?" Aggregate-only is almost always the answer, and it's the reason nothing improves — nobody can see whose estimates are wrong.

AI under financial controls

This is the axis where an AI-and-automation role in Finance differs from the same role anywhere else, and it's where you can be distinctive without being technical.

If it touches financial reporting, controls apply. Practically that means: the process needs documented evidence that it worked, someone independent must review what the automation produced, and access to change it must be restricted. An automation that can't produce its own audit evidence isn't cheaper — it's a control finding waiting to happen.

Segregation of duties survives automation. The person who can change the model cannot also be the person who approves its output. This catches people out: a small team automating its own work can accidentally collapse a control that existed for a reason.

Model changes are changes. If a forecast model is retrained and the numbers move, someone needs to know why. Version the model, keep the training window, and be able to answer "why is this month different" with something other than a shrug.

Straight-through processing rate is the headline metric for any automation of this kind — the share of items that complete with no human touch. It's honest, it trends, and it's the number that shows whether the thing is actually working rather than quietly generating exceptions someone handles manually.

Requirements craft — the artefacts you'd own

Be specific about your own deliverables. Vagueness here is the fastest way to look like a coordinator rather than a practitioner.

UX for finance tools

The role includes UI/UX redesign, and finance interfaces have their own rules. Getting these right in an answer is disproportionately convincing because most candidates default to consumer-app instincts, which are wrong here.

• Density over polish. These are professional users looking at the same screen daily. Whitespace that would be elegant on a marketing site is friction here.
• Every number traceable. Drill-through to the underlying line items, the source system named, and an as-of timestamp on the page. A finance user's first instinct with an unfamiliar number is to distrust it; the interface either answers that or loses them.
• Design the honest states. Stale, partial, still-reconciling, source-system-down. Most dashboards have one state — "fine" — and quietly show yesterday's data as though it were today's.
• Tabular numerals, right-aligned, consistent units. Columns of figures need to be scannable vertically. Mixed units and abbreviated magnitudes cause real errors.
• Export is a feature. They will take it into Excel. Fighting that is a losing battle; design a good export and you'll be thanked instead of routed around.
• No motion, no novelty. Nothing animates in, nothing reveals on scroll. Beyond taste, honour reduced-motion preferences — and never put a number behind an animation.

"Finance interfaces have a different job to consumer ones. The user's first instinct with a number they didn't produce is to distrust it, so the design either answers 'where did this come from' immediately or the tool gets abandoned for a spreadsheet."

Finance vocabulary

You need to use these naturally, not define them. If any are unfamiliar, that's the gap to close first.

Process and requirements vocabulary

AI and automation vocabulary