The Slack thread started on a Tuesday, eleven days after go-live. Finance had posted a screenshot of Stripe next to a spreadsheet nobody recognised. Engineering replied with a link to the admin panel that had shipped in scope. Neither side was wrong. They had simply never written down what “revenue recognised” meant in the product, who owned the export path, or what happened when a subscription changed mid-month.
We have walked into that room too many times. The pattern is predictable: launch feels clean, then the first month-end arrives and the tools disagree. Our view is blunt. Most of that pain is negotiable before a single user hits production—if the CFO and CTO have five specific conversations while the build is still plastic.
The five conversations below are not slide fodder. They are working sessions we run with sticky notes, sample exports, and occasionally a whiteboard sketch of a webhook. When they happen late, we still do them—but the cost is rework, not refinement.
Conversation one: the definition of “done” for money
“Done” for engineering is often deployable code behind a feature flag. “Done” for finance is often a journal entry that ties to a bank statement. Those are different verbs.
We ask both sides to co-sign a one-page ledger: which events create revenue, which create obligation, and which are noise until invoicing runs. For a B2B SaaS client last year, the gap was €40k of recognised revenue sitting in “pending” because webhooks fired before contracts were countersigned. The CTO’s team had built the pipeline the spec described. The CFO’s model assumed legal executed first. Neither spec lived in the same document.
Our working standard is to attach example payloads—real JSON, redacted—to that ledger. When the definitions live next to the data shape, we stop debating whose dashboard is “more true.”
| Event in product | Finance treatment (agreed) | Owner if it breaks |
|---|---|---|
| Trial converts to paid | Recognise on first successful charge | RevOps + eng on webhook idempotency |
| Annual prepaid | Deferred monthly per schedule | Finance owns schedule; eng owns proration flags |
| Credit note issued | Reversal in same period as original | Finance triggers; eng confirms API idempotency |
The table is ugly on purpose. It forces a third column most roadmaps skip: who owns the seam when reality disagrees with the model.
“We did not need another meeting. We needed the same vocabulary on both monitors.”
— CFO, anonymised Series B software company (EU)
We spend time here because small mismatches compound. A rounding rule that differs between Postgres and Excel does not matter on day one. It matters when an investor asks why net retention moved forty basis points and two teams tell two stories.
When the company sells across borders, the ledger picks up another dimension: which tax object attaches to which event, and whether OSS or IOSS applies to a specific line. We do not ask the CTO to become a tax lawyer. We ask which fields in the product are authoritative for place of supply, and we freeze that contract before marketing runs a campaign in a new country. Finance owns interpretation; engineering owns capture fidelity. If those two sentences are not in the same memo, someone will ship a landing page that promises “VAT included” while the cart still prices net of local rules.
Conversation two: who owns the integration boundary
Someone must own the seam between billing, ERP, and the product database. Not “the business” in the abstract. A named owner on each side with authority to say no to scope creep in their lane.
We have seen launches where three vendors—Stripe, NetSuite, a custom middleware—each had a 99.9% SLA on paper, and nobody owned retries when a webhook failed at 2 a.m. on quarter close. The cost was not downtime. It was four people in a war room reconstructing events from logs while the CFO texted the board that numbers would slip a day.
Before launch, we document failure modes: duplicate webhooks, partial refunds, currency rounding at the edge. We assign retry policy and human escalation in the same paragraph. If that feels bureaucratic, compare it to the cost of an emergency bridge call with auditors on the line.
Engineering often wants crisp boundaries: “We expose this API; finance consumes it.” Finance often needs softer edges: “What if Germany invoices late?” Our compromise is a written interface contract with versioning. When finance changes a mapping, it ships like code: pull request, reviewer, deploy window. When engineering changes an event, finance sees the diff before customers do.
Conversation three: what we measure on day seven, not day zero
Launch metrics seduce teams. Sign-ups, activation, time-to-value—they matter. Finance needs a parallel set: gross margin per cohort, cash collection lag, concentration of revenue in top accounts. Those numbers do not appear automatically because we shipped analytics. Someone has to wire the warehouse, map fields, and agree which version of “active user” the board will see.
We push for a written month-one dashboard agreed in week minus four. Not the final stack—just the six charts that will tell us if the machine is lying. If engineering cannot source a field, we say so in writing and pick a proxy. Silence is what creates the Tuesday Slack thread.
A marketplace client wanted “revenue by geography” on day one. The data model supported country at signup, not delivery address. We chose a proxy, wrote it in the footer of the dashboard, and scheduled a hard cutover when the warehouse backfilled. The CFO accepted imperfection for four weeks because the alternative was two teams defending dashboards that measured different planets.
We also name the latency budget for finance data. Near-real-time for operations, T+1 for board metrics—whatever the pair picks, it lands in the same memo as the chart list. Nothing erodes trust faster than a CFO refreshing a tile that engineering knows updates hourly while another tile is daily.
Conversation four: change control when reality drifts
Roadmaps change. Tax rules change. A regulator sends a letter. The mistake is treating those shifts as “product updates” without a finance pass—or as “finance exceptions” without a deployment plan.
We keep a lightweight change log: date, trigger, systems touched, owner, and whether the board needs to know. It sounds small until you are reconstructing why Malta VAT rules broke a report for six weeks. The CTO’s team had shipped a fix in days. Finance discovered it from a customer complaint, not from a release note.
We ask for a standing finance-tech sync that is shorter than most stand-ups and harder to cancel. Not because we love meetings—because drift hides in the gap between “shipped” and “communicated.” When product ships a new seat model, finance should not learn from a tweet-sized Slack message the night before close.
“The product team thought we signed off. We thought we were waiting on schema.”
— Head of Finance, anonymised EU logistics platform
Conversation five: the exit ramp if numbers and product disagree
Disagreement will happen. The question is whether it becomes a culture of blame or a protocol.
We write down: if dashboards diverge by more than an agreed tolerance, who meets, within what window, and what evidence ends the debate—usually a reconciled file from the warehouse, not an opinion from a BI tool. The goal is not perfect alignment every hour. The goal is a single reconciliation path everyone trusts when it matters.
Tolerance should be numeric. “Close enough” is where politics creep in. We have used basis points on revenue deltas and absolute euro caps on small accounts—whatever matches materiality for that business. The CTO gets a voice in materiality too: if the fix is a two-line SQL change versus a two-month rebuild, we want that trade in the open.
We also write down what happens when the warehouse is right and the product UI is wrong—because that happens. The product might round for display; finance must not mistake the rounded figure for the legal one. A single footnote in the dashboard, agreed by both sides, has saved us from more arguments than any new feature flag.
Where this breaks down
This framework frays when one leader treats pre-launch alignment as optional paperwork—or when timelines are so compressed that “we will fix reporting after launch” becomes the plan. We have taken those engagements. The work is harder, more expensive, and it erodes trust between departments in ways no retro fixes quickly.
It also breaks when the organisation runs two sets of books in practice: one for investors and one for operations. We are not the ethics committee, but we will not wire product events to a fiction. In those cases we narrow scope or walk away.
It breaks when heroics replace ownership. If only one engineer knows how billing hooks together, you do not have a system—you have a person. We push for runbooks and pairing before launch, not because we underestimate heroes, but because month-end should not depend on who slept last night.
It breaks when procurement inserts a tool nobody agreed to feed. The prettiest BI layer still needs lineage. We have seen a €9k-per-month “insights” suite sit empty because the warehouse never landed. The CFO blamed engineering; engineering blamed budget timing. The fix was boring: rename owners, freeze new tools for a quarter, ship one pipeline end to end.
It also breaks when sign-off is theatrical. A steering committee that rubber-stamps decks does not replace the ledger. We care less about the slide that says “aligned” and more about the shared folder where both leaders can point to the same CSV on the same day. If your process cannot survive an auditor asking “show me the version finance tested,” it is not a process yet.
Our read
We are not asking CFOs and CTOs to become each other. We are asking them to co-author the constraints the product and the P&L both obey. When that happens early, launch day is an operational milestone, not the start of a negotiation nobody scheduled.
The teams we respect most treat finance and engineering as two implementations of the same reality. Getting there is less about tooling than about the five conversations above—held while the build can still bend. After launch, the same conversations still help—but the room is colder, the budget is spent, and the Slack thread is already public.
That Tuesday thread did not end with a villain. It ended with a calendar invite nobody wanted and a spreadsheet that took six weeks to retire. We would rather spend those weeks before launch, when the only thing at stake is ink—and when both leaders still share the same hallway, not the same blame document.