AI-Forward Finance Engineering
Build-vs-configure, controls and tool-using automation
Build vs configure
After this you can make and defend the build-vs-configure call per problem.
The JD asks for a hands-on developer who still respects an off-the-shelf platform. The signal they want is a person who reaches for code and configuration as tools, with a reason for each.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The seat rewards AI-accelerated building with finance-grade rigor.
Two reflexes fail this interview. The pure-engineer who rebuilds NetSuite's revenue module in Python because the UI annoyed them. The pure-admin who clicks through 200 custom fields and saved searches until the ERP can never be upgraded. The role lives between those and the build-heavy onsite is partly a test of whether you can sit there comfortably.
Frame the call as one question: does the platform's native model fit the requirement or does the requirement exceed it.
- Lean configure when
- The platform's data model already matches the business process
- Lean build when
- Requirements exceed what the platform can express natively
- Lean configure when
- You want vendor support and clean upgrade paths
- Lean build when
- You need custom integration logic the vendor will never own
- Lean configure when
- A future admin must be able to maintain it without you
- Lean build when
- The logic is genuinely novel (usage rating, a custom rev-rec rule)
- Lean configure when
- The capability is commodity - tax, AP, journal posting
- Lean build when
- Speed and correctness depend on testable, version-controlled code
| Lean configure when | Lean build when |
|---|---|
| The platform's data model already matches the business process | Requirements exceed what the platform can express natively |
| You want vendor support and clean upgrade paths | You need custom integration logic the vendor will never own |
| A future admin must be able to maintain it without you | The logic is genuinely novel (usage rating, a custom rev-rec rule) |
| The capability is commodity - tax, AP, journal posting | Speed and correctness depend on testable, version-controlled code |
The same problem can flip between columns as scale grows. Re-ask the question, don't assume last year's answer.
Decide on total cost, not first-build costwho supports it after you
The cheap build is rarely the cheap system. Every custom script, scheduled flow and integration is something that breaks at a vendor release, fails a SOXSarbanes-Oxley Act. A US law that forces companies to keep auditable controls over any system that affects their financial reporting. walkthrough if it's undocumented and pages someone at quarter close. Price the decision over its life, not over the sprint.
- Maintainability
- who edits this in two years and can they without reverse-engineering you
- Upgrade safety
- does a NetSuite or billing-platform release break it and will you know before close
- Auditability
- can an auditor trace and re-perform it or is it a black box
- Support load
- where does the page go at 11pm on the last day of the quarter
A build that scores badly on these is technical debt wearing an engineer's badge.
Over-customizing an ERP into an unupgradeable state is the classic finance-systems implementation failure. Heavy SuiteScript, hard-coded business logic in the GL, custom fields the vendor's release notes never anticipated - each one is fine alone and lethal in aggregate. When the platform can't take the next version, you've built a fork you now maintain forever. Name this risk before the interviewer has to.
Build-vs-buy turns on time, scale and complexityplus your appetite for risk
Cursor's own finance team built their contract-provisioning automation rather than buying it. Buying would have meant system integrations, vendor onboarding and time they didn't have, and they had no spare engineering resourcing to throw at it. So they built. But the same team will tell you to buy when the problem is genuinely complex or a strong dedicated tool already exists - replicating that in-house is the over-build trap in a different costume.
Don't pitch a build-everything worldview. The deciding factors are time, scale and complexity. Build where there's a true unaddressed pain point that's blocking scale, and buy where a dedicated tool already does it well.
“People have been talking about SaaS apocalypse, right? And I don't quite buy into that statement.”
Have one real story where you chose to build and one where you chose to configure, each with the consequence. The build story is stronger if it includes a cost you paid later - the integration you had to babysit, the test suite you wish you'd written sooner. The configure story is stronger if it's where an engineer would have over-built and you didn't. Showing you can resist your own instinct is the point.
Takeaway. Configure when the platform's model fits and you want supportability; build when requirements exceed it - and price the decision on total cost, not first-build cost.
Self-check
QSales needs a quote-approval rule the CPQ tool can express with native approval workflows, but it would take some clicking to set up. An engineer on the team offers to write a custom service instead. What's the stronger call and why?
Engineering hygiene for finance systems
After this you can bring real software discipline to a finance stack.
Most finance-systems work ships by clicking in a production UI with no version control, no review and no test. You are being hired to end that and the JD says so directly: strong convictions about developer tooling, CI/CDContinuous Integration / Continuous Delivery. The automated pipeline that builds, tests and ships code so changes reach production safely and often. and maintaining velocity safely.
The trick is that finance has constraints a normal app doesn't. You can't just push to prod when prod is the general ledger during close. So the discipline has to coexist with segregation of duties and an audit trail, which is exactly the tension the interview probes.
Treat config as codethe foundation everything else sits on
- Export ERP/billing customizations (SuiteScript, scripted rules, integration mappings) into a Git repo so changes are diffable and reviewable.
- Require pull-request review on anything that touches rating, rev-rec or posting logic - a second set of eyes is also a SOXSarbanes-Oxley Act. A US law that forces companies to keep auditable controls over any system that affects their financial reporting. control.
- Pin and document platform versions and dependencies so an upgrade is a planned PR, not a surprise at close.
- Keep secrets and connection strings out of the repo and in a managed secret store with rotation.
Promote changes, don't poke productionenvironment strategy
- 1Develop in a sandbox. Build and iterate against a non-production instance seeded with realistic, scrubbed data.
- 2Open a PR. The change is code-reviewed; the diff and approver become part of the audit evidence.
- 3Run CI. Unit tests, reconciliation checks and a deploy dry-run gate the merge.
- 4Promote to staging. Validate against a production-like dataset and confirm reconciliations still balance.
- 5Release to production under change control. A separate approver promotes; the deploy is logged with who, what and when.
Test the financial logicwhere finance engineering earns its keep
A usage-rating function and an ASC 606The US revenue-recognition standard; cited as the canonical judgment-heavy accounting work to keep human-led rather than hand to an agent, because facts and circumstances vary deal to deal. allocation are pure logic with right answers.
Fixture a contract, assert the schedule and the invoice line.
Edge cases earn tests: mid-period upgrades, true-ups, refunds.
Sum of subledger should tie to GL; metered usage should tie to billed usage.
Run these continuously, not only at close.
A failing recon is a failing build, surfaced before an auditor finds it.
Data fixtures are the unglamorous enabler. A small library of representative contracts, usage records and payments lets every test run deterministically and lets you reproduce a production bug in the sandbox instead of guessing.
“I treat the billing config as a codebase. Everything lives in Git, every change is a reviewed PR that runs unit tests and a reconciliation suite in CI and we promote sandbox to staging to prod under change control. That gives me velocity and an audit trail from the same workflow - the review that protects the close is the same review that catches bugs.”
Risk-tier the merge so a finance team can ship safelyan AI reviewer plus humans where risk warrants
Cursor's finance team builds their accounting apps inside the company mono-repo, in a section reserved for them, and uses PRs as the approval control. Every PR is reviewed by BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs., Cursor's own AI code reviewer, and the gating is tiered by risk. Low-risk PRs merge once Bugbot blesses them. Medium and high-risk PRs still need a human engineer's sign-off. That's how a non-engineering team ships into a shared codebase without becoming a liability.
Auto-merge on low risk keeps the team fast on the boring 80%; a required human approver on medium and high risk keeps a person accountable where a mistake costs real money.
“If they are low risk, they go through without needing any additional approval as long as BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. has given it the blessing. If it's medium or high risk, it still requires an engineer approval.”
Don't pitch a Silicon Valley deploy pipeline that ignores controls. If your answer lets one person write and release a change to the ledger with no second approver, you've failed segregation of duties and you'll lose the audit-minded interviewer. Velocity and controls are not opposed here; the same PR gate serves both.
Takeaway. Put config in Git, gate changes with reviewed PRs and a CI suite that includes reconciliation and promote sandbox→staging→prod under change control so velocity and audit come from one workflow.
Self-check
agent-assisted finance automation
After this you can design AI/agent automation for finance operations responsibly.
The JD asks you to champion AI-forward automation in both development and operations. That's not a vibe - it's a concrete design problem: pick the right targets and put guardrails between a non-deterministic agent and the company's money.
Cursor's finance team splits AI value into two modes, and the split tells you what to build. Mode one is AI as your analyst: you describe a need, get a deliverable back - an investigation, a reconciliation, a memo, a batch of journal entries - use it once and move on. Every ad-hoc SQL query and pivot-table variance hunt lives here. Mode two is AI as your builder: you build something that lives on, a tool or a scheduled job or a workflow with its own audit trail that persists past a single chat.
Interactive widget. Tab through its controls; the result updates in the panel below as you change them.
An investigation often becomes an analysis, which becomes an automation, which feeds a dashboard.
Mode one for the unique and one-off; mode two when the same conversation keeps recurring.
The decision rule is about repetition. Reach for the analyst when the task is genuinely a one-off; reach for the builder the second you notice you keep re-running the same investigation by hand.
“Mode one is when the task is unique or unpredictable or a one-off... mode two is when you catch yourself having those same conversations again.”
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Speed from the draft; trust from the review gate.
Start by picking work that is high-volume, judgment-light and currently eats manual hours. Those are where an agent pays off and where a mistake is cheap to catch.
Match usage→invoice→payment→GL across systems.
Agent proposes matches and flags the residual; a human clears exceptions.
Measure: % of lines auto-matched, exceptions left for review.
Surface a usage spike, a margin outlier, a duplicate invoice.
Output is an alert with evidence, not an automatic adjustment.
Measure: true-positive rate, time-to-detect.
Draft outreach, sequence reminders, propose write-off candidates.
Sending is fine; writing off requires approval.
Measure: DSO movement, recovered AR.
Use Cursor to scaffold an ETL job, a webhook handler, a migration.
Output is reviewed code in a PR, never a live change.
Measure: build time, defects caught in review.
A mode-two automation in the wild: the self-maintaining knowledge basethe chore a human would never get to
Cursor's ops team runs an AI-driven ticketing system that leans on a detailed knowledge base, so the KB has to stay current or the answers rot. They seeded it by having Cursor scrape roughly six months of Slack history through the Slack MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. - learning what got asked, how it was answered and whether the answer actually resolved. Then they built the part that keeps it alive: an automation that runs every 28 days, reviews the prior 28 days of channel messages and proposes new KB entries. It drops a Slack message - here's what I found, do you want to approve these? - and a human clears the gate.
Auditing a knowledge base every month is exactly the task that dies on a human backlog. An automation does it reliably forever, and the approval step keeps a person on the hook for what lands. Note the pattern: it proposes, a human approves - the same shape you want on anything touching the books.
“That's something that you'd ask someone to do and they would just never do it... It would fall to the bottom of the priority list.”
The guardrail: separate what an agent suggests from what it commitsthe line that keeps you out of trouble
An agent can read everything and propose anything. What it must not do is write to the ledger or move money on its own. Draw that boundary explicitly and the whole design gets safer.
- Scope split
- broad read access; write access narrow, gated and human-approved
- Deterministic checks
- wrap the non-deterministic agent in deterministic validations - a proposed journal entry must balance and reconcile before a human ever sees it
- Human-in-the-loop
- an approval gate on anything that posts to the GL, issues a credit or initiates a payment
- Full audit logging
- log the prompt, the proposal, the human decision and the result - the agent's reasoning is part of the audit trail
The pattern is agent-proposes, system-validates, human-approves, system-records. The agent gives impact; the deterministic shell gives correctness; the human gives accountability. That sequence is what lets you say yes to automation that touches finance without saying yes to an agent quietly editing the books.
Prove it with numbers, not adjectives
- Close-time reduction: days or hours shaved off the monthly close.
- Exceptions auto-resolved: share of reconciliation lines cleared without a human.
- Manual hours saved: re-deployed to higher-judgment work, not just deleted.
- Error/exception rate before vs after - automation that raises errors is not a win.
When you propose an agent, lead with the guardrail, not the magic. Say what it can read, what it can never write, the deterministic check that gates its output and the human approval before anything posts. Finance interviewers relax the moment they hear you've thought about the failure mode first. Then quantify the win.
Takeaway. Aim agents at high-volume, judgment-light work and enforce agent-proposes → system-validates → human-approves → system-records so nothing non-deterministic writes to the ledger unattended.
Self-check
QYou want an agent to handle reconciliation. Which design keeps it safe enough for a finance environment?
Controls, SOX & audit
After this you can design automated finance systems that stay auditable.
Cursor is pre-IPO and growing fast and the JD prizes pre-IPO experience for a reason: someone will have to make this stack SOXSarbanes-Oxley Act. A US law that forces companies to keep auditable controls over any system that affects their financial reporting.-ready while it's still being built. Controls aren't a phase after the system; they're a property you design in.
The fear an auditor brings to an automated finance stack is simple: if a machine did it, who's accountable and can I re-perform it. Your job is to make the answer obvious. Three controls cover most of that ground.
- Control
- Segregation of duties
- What it means
- The person who builds or initiates a change can't be the one who approves it
- Evidence it produces
- Distinct author and approver on every PR / posting / payment
- Control
- Access controls
- What it means
- Least-privilege roles; write access to ledgers is scarce and reviewed
- Evidence it produces
- Role assignments, periodic access reviews, deprovisioning logs
- Control
- Change-approval evidence
- What it means
- Every production change is reviewed, approved and traceable
- Evidence it produces
- PR diff, approver, CI result, deploy log tied to a ticket
| Control | What it means | Evidence it produces |
|---|---|---|
| Segregation of duties | The person who builds or initiates a change can't be the one who approves it | Distinct author and approver on every PR / posting / payment |
| Access controls | Least-privilege roles; write access to ledgers is scarce and reviewed | Role assignments, periodic access reviews, deprovisioning logs |
| Change-approval evidence | Every production change is reviewed, approved and traceable | PR diff, approver, CI result, deploy log tied to a ticket |
Notice these are the same artifacts your engineering pipeline already produces - controls fall out of good hygiene.
Immutable trail from source event to journal entrythe spine of an auditable system
An auditor should be able to take any number in the financials and walk it back to the event that caused it. A booked revenue dollar traces to a journal entry, which traces to a rev-rec schedule, which traces to a contract and a metered usage event with an immutable id.
- 1Source event. A usage record or contract change lands with a unique, immutable id and timestamp.
- 2Rated / recognized. Logic turns it into a billing line and a rev-rec schedule, carrying the source id forward.
- 3Posted. A journal entry references the schedule and the source id; the ledger is append-only, corrections are new entries.
- 4Reportable. Any reported figure can be drilled back through the chain to the originating event.
Financial ledgers append, they don't overwrite. A mistake is corrected with a reversing and a new entry, both preserved, never an edit-in-place. The same goes for the audit log of agent and automation actions. "What was the state before this change and who authorized it" must always have an answer, which is impossible if records can be silently mutated.
Controls auditors trust even when agents do the workthe new question for an AI-forward stack
- Log the automation's inputs, proposal and the human approval as first-class evidence - an agent action is a change like any other.
- Keep the human approval gate on anything that posts or moves money, so accountability always lands on a person.
- Wrap agents in deterministic, testable checks an auditor can inspect, rather than asking them to trust a model's judgment.
- Be ready to re-perform: given the same inputs, the controlled pipeline produces the same numbers.
Name the central tension out loud: control rigor versus the speed Cursor expects. Then resolve it instead of just stating it. The resolution is that your controls are mostly automated and ride the same PR/CI pipeline that gives you velocity, so adding a control doesn't add a meeting. That's the answer that proves you can be fast and audit-ready at once, which is the whole reason this role is hard to fill.
Takeaway. Design SOXSarbanes-Oxley Act. A US law that forces companies to keep auditable controls over any system that affects their financial reporting.-ready controls - segregation of duties, least-privilege access, change-approval evidence - into an append-only trail from source event to journal entry and treat agent actions as logged, re-performable changes.
Self-check
QAn auditor asks how a specific booked revenue figure came to be. What property must your automated stack have to answer cleanly and how does it stay true when an agent is involved?
Demonstrating the AI-native mindset
After this you can show, not tell, that you build with AI by default.
Cursor's loop is AI-native to an unusual degree. You'll likely build in Cursor live and the bar is the AI authenticity test: apply judgment to AI output, debug it, reject bad suggestions and never paste raw model output into the books.
Telling them you're AI-forward does nothing here. Everyone says it. The proof is a specific story and a fluent hands-on session, so prepare both.
Bring one concrete story - including the rejectionthe rejection is the part that lands
- 1The task. A real thing you shipped - an integration, a migration, a reconciliation tool - with a before-time and an after-time.
- 2the impact. Where AI made it materially faster or better, concretely: scaffolded the ETL, generated the test fixtures, drafted the mapping.
- 3The rejection. The moment you caught the model wrong - a subtly off rev-rec rule, a mishandled edge case, a hallucinated API - and what you did instead.
- 4The verification. How you confirmed the final result was correct: tests, reconciliation, a tie-out, a review.
“I had Cursor draft the Stripe-to-NetSuite reconciliation job and it got me 80% there in an afternoon. It also confidently proposed a match rule that would've double-counted partial refunds. I caught it because the reconciliation test didn't balance, rewrote that piece by hand and added a fixture for the refund case so it can't regress. AI did the volume; I owned the correctness.”
Be fluent in Cursor's own workflowyou may be building in it on the call
- Agents
- delegate a multi-step task, then read and steer the plan rather than accepting it whole
- Codebase context
- point the model at the right files so it answers from your code, not its priors
- Edits & review
- accept, reject and refine proposed diffs deliberately - your review is visible and being graded
- Verify in the loop
- run the tests or the recon as you go, so correctness is continuous, not a final hope
- Model choice
- let Auto route per task - the in-house ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. models for data and query work, a frontier general model for prose like a memo
Pick the model to the task, or let Auto do it
Cursor's in-house ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. models are engineering-tuned, so they shine on the data and analytical side of finance - queries, reconciliations, anything code-shaped. For writing prose like an accounting memo, a general-purpose frontier model is the better fit. The practical move is Auto modeA router that reads your prompt and picks a model for you, defaulting to Composer; you steer it with cues like "quickly" or "carefully".: it reads the request and routes to the right model in the moment, Composer for a pure coding task and a frontier model when you're drafting a memo. You rarely have to think about it.
Interactive widget. Tab through its controls; the result updates in the panel below as you change them.
Plan with a thinker, execute with a fast model.
Composer for queries and reconciliations; a frontier model for prose; Auto to route when you're not sure.
Don't memorize a model matrix. Know the split - engineering-tuned for data, general-purpose for writing - and trust Auto to apply it.
“If you are writing an accounting memo, maybe a general model makes sense, but if you run it on auto mode, it's really good at determining the right model for the right task.”
Frame AI as the answer to the structural problem of the role. You are a solo function covering Order-to-Cash and Record-to-Report at a company sprinting toward multi-billion ARR. AI is how one person covers a team's surface area and saying that connects your tooling to the JD's explicit ask to champion AI-forward automation in development and operations.
The failure mode they're screening against is over-trusting AI where wrong numbers carry audit and revenue consequences. If you ever imply you'd ship model output without verifying it against a test or a reconciliation, you've confirmed their worst fear about AI in finance. Pair every claim of speed with the check that caught the error.
Takeaway. Don't claim you're AI-native - demonstrate it with a story that includes the moment you rejected the model, plus fluent live use of Cursor's agents, context and review, always backed by a verifying test or reconciliation.
Self-check
QIn the live build, Cursor generates a rev-rec allocation that looks plausible and runs clean. What demonstrates the AI authenticity bar the loop is testing for?