Finance and sales teams often argue about revenue because they are answering different questions with the same number.

Finance needs closed periods, ledger accuracy, and an audit trail. The sales needs to understand new business, expansion, contraction, churn, and current run-rate.

Both views are valid. The problem starts when booking, billing, recognition, and cash are mixed in one model or when each dashboard rebuilds the logic differently.

In this article, I’ll walk through a framework that keeps Finance and Sales on the same page without compromising business insight or finance auditability. The goal is also to make the logic explicit enough for AI agents to act on safely: every metric has a definition and every case is reconciled.

1. Keep four timelines separate

A subscription produces four different numbers. Each answers a different question.

Timeline Question Core measures Primary owner Booking What did the customer commit to? MRR, ARR, backlog Sales Ops / FP&A Billing What did we invoice or credit? Invoices, credit notes, deferred revenue Finance Recognition What did we earn? Recognized revenue Accounting Cash What did we collect or refund? Collections, refunds, AR Finance

Rule: never use a measure from one timeline to answer a question from another.

MRR is a contractual run-rate. It must not be derived from recognized revenue, because recognition includes proration and accounting rules that do not represent a change in the recurring base.

One contract, four correct answers

Take a twelve-month contract signed on January 15:

• €1,200 monthly run-rate

• €14,400 billed annually upfront

• Net-30 payment terms

No number is wrong. They describe different timelines.

2. Record three dates for every event

Every revenue event needs three dates:

Date Meaning Question it answers Economic period When the event relates to economically What happened in the business? Booking period When the event hits the books or governed report Which closed period owns it? Known at When the information entered the system What did we know at close?

This solves the late-data problem without silently rewriting history.

If a June churn is received on July 3:

economic_period = June
booking_period = July if June is closed
known_at = July 3

The model can reproduce both June as reported at close and June as understood today.

Rule: a closed booking period never changes silently. Every change requires an explicit adjustment or restatement event.

3. Use one canonical event model

The canonical event model is the shared ledger between source systems, Finance controls, and the semantic layer. Its purpose is not to precompute every dashboard metric. Its purpose is to preserve each business event once, with enough context to derive and reconcile every view.

What the model must contain

Use one row per source-backed business event:

revenue_event(
  event_id,
  customer_id,
  subscription_id,
  event_type,
  economic_period,
  booking_period,
  known_at,
  currency,
  mrr_delta_local,
  billed_amount_local,
  recognized_amount_local,
  cash_amount_local,
  fx_rate_frozen,
  fx_rate_closing,
  definition_version,
  source_system,
  source_record_id,
  related_event_id,
  adjustment_reason
)

Each field has one responsibility:

• mrr_delta_local records a contractual change in recurring run-rate.

• billed_amount_local records invoices and credit notes.

• recognized_amount_local records earned revenue and reversals.

• cash_amount_local records collections and refunds.

• known_at makes historical reports reproducible.

• definition_version makes metric changes traceable.

• source_system and source_record_id provide lineage.

• related_event_id links reversals, credit notes, and corrections to the original event.

• adjustment_reason makes exceptions explicit rather than hiding them in transformations.

Amounts not affected by an event remain zero or null. If one commercial action creates several accounting records, preserve the source-level records and link them through a common business-event identifier.

Examples by business event

Business event Event type MRR delta Billed Recognized Cash New €1,200 MRR contract, invoiced annually

The important distinction is between capturing events and interpreting movements. The canonical model captures the facts. The semantic layer classifies customer-period movement consistently for every dashboard, analyst, and agent.

4. Build reconciliation into the event model

Reconciliation is the control framework that validates how canonical events move through the four timelines.

Each event must retain its source, accounting effect, commercial effect, dates, currency treatment, and links to reversals. That design makes five common distortions:

5. Add a governed semantic layer for humans and AI

The event model answers what happened. The semantic layer defines how the business talks about it.

This is where stakeholders define metrics once and expose them consistently to BI tools, analysts, operational workflows, and AI agents.

For every governed metric, publish a machine-readable contract:

An agent should not infer whether “revenue” means bookings, billings, recognized revenue, or cash. The semantic layer must supply the definition, valid dimensions, time policy, and reconciliation status with the data.

A governed answer should therefore return not only a value, but also its metric version, as-of timestamp, close status, and control status. If the requested slice is not governed or a reconciliation has failed, the agent should say so rather than fabricate a precise answer.

6. Run controls for the release

Release rule: if one reconciliation fails above the agreed tolerance, governed metrics and agent answers do not publish.

Control 1: MRR bridge

Opening MRR
+ New and reactivation
+ Expansion
- Contraction
- Churn
= Closing MRR

Control 2: Revenue to general ledger

Recognized revenue by booking period
+/- explicit revenue adjustments
= General ledger revenue

Control 3: Deferred revenue

Opening deferred revenue
+ Invoices creating deferred revenue
- Revenue recognized from deferred balances
- Credit notes applied to deferred balances
+/- FX and explicit adjustments
= Closing deferred revenue

Credit notes do not always affect deferred revenue in the same way. A credit issued before recognition reduces the deferred balance. A credit issued after recognition may reverse revenue, create a refund liability, or affect AR instead. The event must identify the original invoice or recognition entry through related_event_id, and the reconciliation must route the effect according to the accounting treatment.

Control 4: AR and cash

Opening AR
+ Invoices
- Collections
- Credit notes applied to AR
+/- explicit adjustments
= Closing AR

Minimum automated tests:

• Every event has a valid type, source record, economic period, booking period, and known_at timestamp.

• Source records are unique, or duplicates have an explicit versioning rule.

• Contract changes explain every MRR delta.

• A churn classification ends at zero MRR and has a confirmed loss signal.

• Movement totals equal the change from opening to closing MRR.

• No event silently posts into a closed booking period.

• Every credit note or reversal links to the event it corrects.

• Every FX residual lands on a translation line.

• Every restatement has a reason, owner, timestamp, and definition version.

• Revenue, deferred revenue, AR, and cash tie to their authoritative systems within tolerance.

7. The architecture in one view

The separation of responsibilities is deliberate:

• Sources record operational and accounting facts.

• The canonical event model preserves those facts consistently.

• The reconciliation framework proves that the model ties to authoritative systems.

• The semantic layer turns reconciled facts into governed business concepts.

• Consumption tools and agents query governed concepts rather than rebuilding logic.

Conclusion

Trust between Business and Finance is built when both teams can start from the same customer movement and follow it to the same financial outcome.

When every new contract, expansion, contraction, and churn can be reconciled to revenue, margin, and cash, Finance stops being only the team that validates the past. It can explain which customers, products, and movements create profitable growth and where the business should invest next.

That is how finance insight becomes a growth engine through a shared, reconciled model that turns every customer movement into a decision both Business and Finance can trust.

Finance Shift is a newsletter on the intersection of finance and engineering. If this was useful, share it with someone who want to build its own.

• 56% of finance leaders use AI today (vs. 17% in 2023)

• 68% of CFOs say they’re slow to adopt because they don’t know where to start

This isn’t a technology problem. It’s a skills problem.

What this role is not

In France, “ingénieur financier” refers to a quant: someone who models derivatives, calculates VaR, writes Python to price options. That’s financial engineering, a discipline born out of mathematics and trading floors.

The Finance Engineer this article is about has nothing to do with that. This person sits inside your internal finance team. Their mission: build the systems that automate everything your team currently does manually, and keep those systems running continuously.

What made this role possible

Tools have evolved faster than org charts. Connecting Claude to a data warehouse via MCP no longer requires a developer. Building a reconciliation workflow in n8n takes a few hours. The barrier between “understanding financial logic” and “encoding that logic into a system” has nearly disappeared.

The market confirms it in numbers:

• Gartner: 90% of finance teams will deploy at least one AI solution by the end of 2026

• Gartner: embedded AI in cloud ERPs will cut the close cycle by 30% by 2028

• BCG: 75% of finance leaders expect agentic AI to be commonplace within 3 years

Job postings follow the trend. Discord’s 2026 postings call for using AI agents like Claude Code and Codex to automate reporting. MLB Network is hiring a “Financial Analyst, FP&A and Systems” whose core mission is building pipelines that connect ERP, reporting, and operational systems. Spring Health has created an official title: Senior Finance Engineer, $159,000, reporting to the VP of FP&A.

The title varies. The need is the same everywhere.

What it costs not to have this profile

OpenAI’s finance team operates with 22% of the headcount of comparable tech firms. An internal bot reads contracts, applies ASC 606 revenue recognition rules, and generates journal entries. What ten people used to do manually, a system now does continuously.

The median ROI on AI initiatives in finance sits at 10% according to BCG, but one team in five already exceeds 20%. The gap between organizations with the right profile and those still waiting is widening.

What the market says

In the US market, compensation is settling into three tiers:

Level US Salary Reference Junior hybrid FP&A + systems $90k – $100k MLB Network Mid-level, confirmed AI fluency $116k – $130k Discord Senior, full ownership of the automation stack $159k – $179k Spring Health

This isn’t a finance analyst’s salary. It’s an engineer’s salary. Wolters Kluwer’s 2025 survey (392 respondents) confirms that 85% of finance leaders consider AI skills important in their hiring criteria.

In Europe, the structural gap versus the US runs around 40%. According to Finance Alliance, an FP&A manager earns on average $75,714 in Europe versus $132,500 in North America. For a senior Finance Engineer, this puts the role between €90k and €120k depending on the country, with London and Amsterdam at the top and Paris slightly below.

Proof the role exists in France: Pigment posted a Finance Systems Engineer role in Paris in June 2026. Description: 50% systems architecture (Pigment, NetSuite, Salesforce), 30% AI automation (LLM agents, n8n, APIs). Expected profile: 3 to 6 years in FinOps or RevOps, LLM proficiency, financial fluency.

In France, the role is still being hired under scattered titles: “Finance Business Analyst,” “FP&A Automation Specialist,” “Responsable Outils Finance” (Finance Tools Manager). There’s no standardized title yet. Search by skill set, not by job title.

The two profiles you’ll encounter

Profile 1: The finance person who learned to build

• 5 to 8 years in FP&A or accounting

• Got frustrated with existing tools, then moved into automation

• Has shipped something to production: automated reconciliation, a live dashboard, a KPI alert

• No computer science degree, but real systems running in production

• Rarer, more expensive, immediately operational

Profile 2: The technologist who pivoted into finance

• Background in RevOps, analytics engineering, or a data team

• Understands pipelines, APIs, automation tooling, data transformation

• Needs training on accounting and audit constraints

• More accessible, longer ramp-up

The Finance Engineer’s skill set

In its Finance Engineer Defined report (June 2026), CFO Connect identifies two layers of skills. Both are required.

Technical layer

• LLM proficiency: orchestrating agents that pull live data, apply logic, and flag exceptions on their own.

• Workflow automation: identifying friction points and eliminating them. A data pull that refreshes itself. A weekly reconciliation that surfaces exceptions without manual intervention.

• Data literacy: working with SQL, querying a data model without depending on IT, recognizing an incomplete data source before it flows into a downstream system.

• Systems integration: connecting tools via API or middleware, understanding how data flows through the ERP.

Behavioral layer

56% of finance professionals rank workflow automation as the most important AI skill for their career over the next two years (CFO Connect, State of AI in Finance 2026). But technical skill alone isn’t enough.

The Finance Engineer must also be able to:

• Explain what they’re building to non-technical stakeholders

• Prioritize automations that deliver real value

• Drive adoption within the team

• Test new tools without waiting for a complete playbook

The decision you’re making by hiring or not

There’s an apparent alternative. AI vendors are now deploying Forward Deployed Engineers directly inside client organizations. OpenAI just acquired Tomoro for 150 of these profiles. Anthropic launched a joint venture with Blackstone, Hellman & Friedman, and Goldman Sachs on the same model.

The distinction is simple: an FDE brings a mature, proven stack, deployed quickly. A Finance Engineer builds a stack that belongs to your business logic, evolves with your needs, and stays in place after the vendor contract ends. Both have value. Over a two-year horizon, the economics favor the in-house hire.

Finance remains last among all business functions in AI adoption — not because the tools are missing, but because no one inside the function owns it. The Finance Engineer is that owner. Specifying what they’re going to build is your job, before it’s theirs.

Happy to hear your thoughts and experience on how to hire for this role 👇

Finance Shift is a newsletter on the intersection of finance and engineering. If this was useful, share it with someone who want to build its own.

Job postings referenced: Spring Health · Discord · MLB Network · Pigment

Sources: CFO Connect State of AI in Finance 2026 · CFO Connect Finance Engineer Defined (June 2026) · Gartner (Sept. 2024; Feb. 2026) · BCG How Finance Leaders Can Get ROI from AI (2025) · Wolters Kluwer / CCH Tagetik Survey (May 2025) · Finance Alliance Salary Report 2025 · OpenAI Deployment Company (May 2026) · Anthropic Enterprise AI Services (May 2026)

But that code is not readable. A finance controller cannot open an HTML file and verify whether gross margin was calculated correctly. They see a number, not the rule behind it.

That is why the quality of a Claude financial dashboard is not determined at generation time. It is determined in the preparation of the prompt, and in what you ask Claude to include to make the result auditable.

Here are the four steps that make the difference.

1. Document your input data

Before writing anything in Claude, prepare a documentation file for your data sources. For each table or file: its name, what it contains, and the definition of each column with its business meaning.

The best way to maintain this file: a Notion page connected via MCP. Claude can read it directly at the start of each session without copy-pasting. It stays maintained, versioned, and accessible to the whole team.

2. Define every metric without exception

In your final prompt, every indicator must be defined. Leave no room for Claude to apply its own formula.

The simplest way: use Excel dialect. You do not need to know Python or SQL. If you can write a SUMIF, you can specify a calculation for Claude. Transposing it into the execution language of its choice is Claude’s job.

Not “calculate gross profit”. This:

### Calculations are encoded with Excel dialect 

Net revenue     = SUMIF(AccountNum,"70*",Credit) - SUMIF(AccountNum,"70*",Debit)
                 - SUMIF(AccountNum,"709*",Credit)

Direct costs    = SUMIF(AccountNum,"607*",Debit) - SUMIF(AccountNum,"607*",Credit)

Gross profit    = Net_revenue - Direct_costs - Inventory_variation

Every dashboard indicator has its own line. No implicit formula, no decision left to the agent.

These formulas live in the same Notion file as the data documentation from step 1. One reference document: the columns, their meaning, and the calculation rules that apply to them. Every team member, every dashboard, every spreadsheet refers to it as the single source of truth.

3. Have Claude retranscribe what it is about to encode

Before generating the dashboard, ask Claude to produce a glossary page: a plain-language display of every calculation it is about to encode.

This is a verification step, not a validation with domain experts. That was already done in steps 1 and 2. The goal here is simple: read in plain language what Claude understood from your specifications before it writes any code.

The glossary shows:

• Each indicator with its definition restated in plain language

• The calculation rule line by line as Claude understands it

• The exclusion conditions it will apply

• The reconciliation checks it will integrate

If the glossary says something unexpected you fix it before to move to dashboard construction.

This glossary then becomes a permanent tab in the generated dashboard. When a number is surprising, anyone on the team can open the Methodology tab and read exactly what was calculated and how. The dashboard becomes auditable without opening the code.

4. Build the dashboard iteratively

This is the only step that happens in conversation mode, not as a single prompt. Iterative means: one thing at a time, with validation at each step.

Start with a simple layout: KPI cards and one chart. Verify the numbers match your glossary. Add the next chart. Verify. Repeat.

This step-by-step approach lets you catch a discrepancy immediately, before it propagates to ten other indicators. You can also use existing skills to accelerate certain parts, and share screenshots of market tools or Excel files to guide the design.

At the end of each session, ask Claude to save your specification to memory in a structured way. This lets you resume the project from any specific point without starting from a blank page. The spec should never live only in conversation history.

What this produces

The dashboard becomes a commodity. The specification is the real work.

Once the dashboard is built and validated, you have two durable assets: the code itself, which encodes the rules precisely, and the incoming data documentation. These are the best specifications you can hand to an agent to rebuild or evolve the dashboard.

The foundational work, documenting the data, formalizing the metrics, validating the glossary, is documentation work. Once done, generating the dashboard becomes the simplest step in the process.

Finance Shift is a newsletter on the intersection of finance and engineering. If this was useful, share it with someone who want to build its own.

I applied that framework to a concrete finance use case: FEC analysis, the “Fichier des Écritures Comptables”, the standardized accounting file every French company must produce for a tax audit. Standardized format, well-defined business scope, repetitive use, high need for reliability and traceability. A perfect case.

The three failure modes every analytics agent runs into

Anthropic identifies three root causes behind almost every wrong answer.

Concept-entity ambiguity

The model doesn’t know which field corresponds to the concept it’s been given. Without explicit answers, the agent guesses and often guesses wrong.

Data staleness

On the FEC, a concrete example: a company switches TVA regime mid-year, moving from standard to reduced rate on part of its revenue. Any pattern built before that change will silently misclassify those entries going forward. The agent keeps running, the numbers keep coming out, and nobody notices until someone checks manually.

Anthropic measured a drop from ~95% to ~65% accuracy within one month before treating maintenance as an engineering problem.

Retrieval failure

The right information exists in the data but the agent can’t find it and improvises.

On the FEC, it looks like this: the agent receives the question “which suppliers have late payments?” and without structure, it scans through all entries, hesitates between account types, confuses the relevant account classes, and produces an approximate or incorrect answer. The information was there. It didn’t know where to look.

You have to give a structured context, explicit routing, and validation at every step. It’s what we will see across the following method :

The method: four layers

Layer 1 : Data foundations

The prerequisite for everything else: the data must be in a computation engine queryable in SQL. An LLM doesn’t calculate.

For the FEC, I chose to load the entries into BigQuery with the official DGFiP schema: JournalCode, EcritureDate, CompteNum, Débit, Crédit, PièceRef. One table, one source, one schema.

Anthropic’s core concept here is canonical datasets: one governed source per concept. On a FEC, that means one single entries table, not several coexisting partial exports. The more candidates exist, the higher the ambiguity risk.

Layer 2 : Sources of truth

Once the data is structured and validated, the agent needs the business expertise to interpret it correctly, not just the schema.

This layer has two components. First, entity context qualification: sector and size are inferred upfront from the account structure. A weekend cash entry is abnormal in a consulting firm and perfectly normal in a restaurant. All alert thresholds are calibrated from this context before any query runs.

Second, the 7 reference domains that encode business expertise:

• validation : structural integrity of the file

• cash : bank balances, cash low point, cash movements

• performance : revenue, expenses, margins, result

• clients : receivables, DSO, concentration, outstanding invoices

• suppliers : payables, DPO, LME compliance, late payments

• anomaly : atypical entries, round amounts, out-of-norm operations

• compliance : VAT, sequence gaps, atypical OD regularizations

Each file encodes the business context, the analysis patterns with their explicit assumptions, and the gotchas specific to the French accounting context. Rather than letting the agent decide what DSO means, the fec-clients domain tells it exactly: which accounts are included, what’s excluded, how to handle outstanding credit notes.

Layer 3 : Progressive disclosure

Well-documented domains aren’t enough if the agent loads everything at once for every question. That’s the monolithic prompt problem: expensive, noisy, unreliable.

Anthropic’s solution is progressive disclosure: the agent loads only the context defined in Layer 2 that it needs, when it needs it.

For the FEC, I built a router that classifies each request before loading anything. Here’s what it looks like concretely:

This is the direct answer to retrieval failure: the agent knows exactly where to look before it starts, within the context defined in Layer 2.

Layer 4 : Validation

This layer operates across three distinct levels :

• Deterministic Quality Checks

  Mechanical verifications on produced results. These are not judgment calls fixed rules that run automatically:

  • Does the calculated balance match what’s expected for this period?

  • Is the number of rows returned consistent with the entity’s size?

Exemple

• ΣDébit = ΣCrédit: if the file is unbalanced, everything stops. Analyzing a corrupted FEC is more dangerous than producing nothing.

• Schema completeness: all required columns are present and correctly formatted.

Here’s what the integrity check actually looks like:

-- If this returns a row, the FEC is unbalanced.
-- The agent stops here. No analysis runs.

SELECT 
    ROUND(SUM(Debit) - SUM(Credit), 2) AS balance_gap
FROM {dataset}.{table}
    HAVING balance_gap <> 0

If this returns a row, everything stops. No partial report, no approximate results.

• Adversarial Review

  An agent acting as LLM-as-judge receives the question, the SQL query produced, and the result, and actively challenges every element:

  • The review : Was the right filter applied? Is the denominator correct? Is there an interpretation bias?

  • The impact : Anthropic measured +6% accuracy from this layer.

  • The trade-off : For accounting analysis, the choice is straightforward: an undetected error in a financial report costs far more than a few extra seconds.

• Auditability

  A figure without provenance is not usable in a professional context. Every result carries the full trace of how it was built:

  • Domain · Pattern · Human readable SQL translation · Filters · SQL

What this produces

• An agent that takes a raw BigQuery dataset and generates a structured report across all 7 domains, with traceable figures, deterministic controls, adversarial review, and full provenance on every result.

• Instant answer from the chat.

Why it’s replicable

✨ The FEC is the application case. The method is generic.

The four layers apply to any repetitive financial analysis: budget-versus-actual variance, multi-entity consolidation, cash flow forecasting, financial due diligence. The domain changes, the structure stays the same.

The question Anthropic’s article reframes isn’t “is the model good enough?” It’s “have I built the architecture that lets it be accurate?”

In most finance teams, the answer is no. Not from lack of skill. Because this architecture isn’t yet the norm.

It should be.

If you want me to receive the skill send me a message !

Finance Shift is a newsletter on the intersection of finance and engineering. If this was useful, share it with someone who still thinks the problem is the model.

Subscribe now

Pennylane is great for accounting. But its P&L analytics? Still pretty limited. So instead of waiting for the vendor to ship the feature, they pulled the data via API, mapped it in Excel, fed it to Claude, and built the dashboard they actually wanted. Revenue by category, margins, period comparisons, the view that doesn’t exist out of the box.

A few hours to prototype. No dedicated engineer, no BI tool, no extra subscription, just tokens.

Then a few more to make it reliable: clean definitions, access controls, and checks you can trust.

The data was always there. The decision was to stop waiting and start building.

That shift has a name: Finance Engineering.

This isn’t “more dashboards.” It’s finance teams upgrading the system that produces the numbers.

The old model is breaking

For most of finance history, the job was to execute with precision. Close the books. Reconcile the accounts. Report the numbers. Do it accurately, do it on time, do it again next month.

The tools changed: Excel replaced paper, ERPs replaced Excel, but the posture stayed the same. Finance was a consumer of systems built by others.

That model is breaking.

Not because finance teams are suddenly hiring engineers. But because the distance between “I see a problem” and “I built a solution” has collapsed. The same person who closes the books can now build the automation that speeds up the close. The same Controller who runs the reconciliation can build the agent that runs it for them.

The shift isn’t about coding. It’s about ownership. Finance is moving from executing processes to architecting systems.

What a system builder actually does

Three things, concretely:

Structure the data first. One source of truth. Clear definitions. Consistent mapping across ERP, CRM, payroll, banks. This sounds unglamorous until you’ve tried to run an AI on messy data and watched it confidently produce garbage. System builders fix the foundation before they build on top of it.

Turn recurring work into workflows. Close tasks, reconciliations, approvals, controls, reporting. Everything that runs on a schedule and follows rules is a candidate for automation. Not because headcount needs to shrink but because the team’s time is worth more than chasing data. A workflow that runs reliably at 2am is better than a task that waits for Monday morning.

Make AI useful and safe. Anyone can demo a spreadsheet agent. The system builder makes it production-grade: audit trails, controls baked into the architecture, logic versioned so it can be reviewed. They know the output has to survive an audit. So they build like it will.

Why now

For years, finance teams wanted to build. They saw the inefficiencies. They had the ideas. But every data pipeline, every API connection, every custom dashboard meant filing a ticket and waiting for engineering to have bandwidth.

That bottleneck is gone.

Tools like Claude Code and MCPs let you connect AI directly to your enterprise data. What used to take a sprint and an engineering team now takes a weekend and a terminal.

The structural barrier that held finance teams back is dissolving. The question now is who moves first.

The five dimensions of the shift

Not everyone makes this transition the same way. But I’ve noticed five dimensions that define how far along someone is:

Data: Do you understand where a journal entry comes from, how it moves through integrations, where your ERP’s data model will fight you? This is the foundation. Weak here, nothing else holds.

Build: Can you ship an automation into production? Not just prototype it, run it on real data with real consequences.

Controls: If a machine is going to touch the ledger, discipline has to be baked in from day one. Audit trails. Versioned logic. Review steps that don’t disappear because the deadline moved up.

Stack judgment: The teams that look smart in two years won’t be the ones that built the most. They’ll be the ones that built the right things and bought the rest from vendors who’ve already solved security and infrastructure at a depth no finance team should try to replicate.

Accounting intelligence: You can’t automate what you don’t understand, and you can’t evaluate what an agent built if you wouldn’t know how to do it yourself. This is what keeps the whole system honest. A Finance Engineer is still, at their core, an accountant.

No one scores high across all five immediately. The strongest people I’ve seen are intentional about two or three, and clear-eyed about where they lean on their team or their vendors. Nobody masters all five at once. My strengths are data, controls, and stack. I’m still pushing on building and accounting.

How to start

Every Controller I’ve spoken to says the same thing: start with one problem you already hate.

Not a moonshot. A specific, recurring pain that costs you two hours every week. Then try to automate it.

Use Claude. Connect to your ERP via MCP if you can. Write and compute into your data warehouse. Fail, break things, fix them.

And if you’re going to learn one technical concept: understand MCPs. They’re what connects AI to your actual systems. Once you’ve connected one, you’ll immediately see a dozen things you want to build.

Why I’m building Finance Shift

I’ve spent years at the intersection of finance and data. I co-founded Modern Data Network, 1000+ french data leaders, to help Data team to adopt modern data practices.I watched data teams go through the exact same transition finance is going through right now the moment when tools like dbt and Airbyte finally caught up to what data practitioners had always wanted to do: own the entire pipeline, version the logic, and ship without filing a ticket.

That moment happened fast. Faster than most people expected. But what accelerated it wasn’t just the tools, it was the community. People sharing what they built, what broke, what worked. The group leveled up together.

Finance is at that moment now.

Finance Shift exists because this transition deserves a real community. A place where CFOs, Controllers, FP&A leads, and accountants share what they’re actually building, learn from each other’s mistakes, and figure out together what the profession is becoming.

Data is where I’ll spend most of my energy educating, because every system builder story I’ve heard starts the same way: someone finally got their data in order. Then everything else became possible.

If you’re making this shift, or trying to, Finance Shift is where that conversation is happening.

Subscribe now

Share