Building products in fintech, SaaS, and AI is rarely just about shipping features. These products sit inside complex operating environments where customer experience, data flows, financial processes, compliance requirements, and technical scalability all need to work together.

Billing is a good example. On the surface it looks like a narrow operational function. In practice it's where the hardest product and business decisions converge: pricing, usage data, contracts, payments, invoicing, accounting standards, reporting, regulatory compliance.

When these pieces are aligned, monetisation becomes a genuine growth lever. When they're not, the gaps show up fast. A customer upgrades mid-month and gets charged twice. A usage credit is promised by Sales but never appears on the invoice. A refund requires three support tickets because billing, payments, and accounting each show a different version of the truth. Those aren't finance problems. To the customer, they're product failures.

Here are five lessons I've learned:

1. Multiple platforms are hard to keep in sync, and that slows growth

A company starts with a focused product. Volumes grow, new features get added, expansion happens. Healthy. But how you architect that expansion determines your long-term execution speed.

Adyen is a strong example of what a single-platform philosophy can unlock: control, consistency, speed. The lesson isn't that every company should build everything in-house. It's that critical systems (payments, billing, pricing, reporting, accounting) need to work from the same source of truth.

When they do, teams can launch new features and adapt commercial models without constantly reconciling data behind the scenes. When they don't, every change becomes a cross-system coordination problem and growth slows.

When infrastructure is built on mismatched methodologies, the tax shows up in engineering velocity and financial visibility.

2. What feels fast today can slow you down later

Speed matters at launch. You want to ship an MVP, learn from customers, pivot quickly. But speed should matter just as much later, when the product needs to scale.

As products grow, complexity compounds. A simple customer-facing feature can create downstream requirements across payments, billing, reconciliation, compliance, reporting, revenue recognition, and financial close. The customer sees one transaction. Internally it touches many teams and systems.

This doesn't mean overbuild from day one. That slows learning and delays market feedback. But it does mean the most important downstream consequences should be considered early, especially the data foundation. You need to know what was sold, consumed, invoiced, paid, reported, and recognised, and you need to get to that information fast.

Build fast for launch. Design so you can keep moving fast at scale.

3. Every pricing change is an accounting event, and complexity stacks up

A SaaS company starts with flat subscription pricing: one contract, one recognition pattern. Then commercial teams introduce usage-based pricing, credits, and bespoke enterprise commits to drive growth.

Almost every one of those decisions creates an accounting consequence governed by strict regulatory frameworks like ASC 606 and IFRS 15. Finance can't calculate these approximately. They have to be audit-ready.

The Anatomy of a €120k Enterprise Deal

Take a contract with three components: a €60k platform fee, a €40k usage commitment, and a €20k implementation fee. Total cash collected: €120k. Two complications follow immediately.

• Timing mismatches: the platform fee is recognised ratably over the contract term, usage as consumed, the implementation fee only upon onboarding completion. Three clocks running at different speeds. If your billing engine doesn't track them independently, revenue lands in the wrong period.

• Bundle discounts: if those components normally cost €145k, the customer received a €25k discount. Under ASC 606, you can't allocate that discount arbitrarily to the implementation fee to pull revenue forward. It has to be spread proportionally, permanently changing the recognition timeline.

Throw in a mid-year upgrade and the entire future waterfall must be recalculated without touching what's already been recognised. PricingSaaS data tracking 498 software companies found that pricing restructures were the single most common commercial event in 2025, alongside a 126% YoY increase in credit-based models. Most billing systems aren't built for that pace of change.

4. Data architecture is what makes regulatory scalability possible

Fast dashboards, painless debugging, reliable trend analysis: those aren't frontend wins. They're data model decisions made early that either pay off indefinitely or consume your team's time indefinitely.

The stakes get higher the moment auditors, regulators, or investors come in. In financial products, knowing revenue was generated isn't enough. You need to prove what was sold, when it was delivered, how it was priced, what was invoiced, what was paid, and when recognition was allowed.

In 2023, the SEC charged former executives of Pareteum, a telecommunications and cloud software company, with accounting and disclosure fraud. The company had recognised revenue from purchase orders before the underlying obligations were satisfied, overstating revenue by $12 million in 2018 and $27 million across the first two quarters of 2019.

The data required to prevent that usually exists somewhere in the system. The question is whether your architecture can surface it cleanly: from contract, to usage, to invoice, to payment, to revenue recognition. If engineering or finance has to manually extract, transform, and stitch that trail together every reporting cycle, you're not scaling. You're creating regulatory risk.

Compliance requirements can't be treated as a ticket raised by a controller six months after launch. They need to be design specs from day one.

5. The features customers love are the ones that break accounting

There's a natural friction between product marketing and financial operations. The commercial features designed to reduce churn, drive adoption, and keep users happy are frequently the ones that introduce the most complexity to the ledger. They run on the same data.

Subscription pauses: a simple button click for the user. For the accounting engine, it triggers a contract modification under ASC 606. Did you extend the term? Change the total transaction price? Both? The entire future revenue waterfall has to be recalculated.

Coupons and free trials: acquisition tools to marketing, variable consideration or a material right to finance. Depending on whether a discount is incremental to standard pricing, it shifts how much revenue you're allowed to recognise on day one versus day one hundred.

Real-time spend alerts: the exact same usage-consumption data the notification engine needs is what finance needs to recognise revenue at month end. If they don't share a single source of truth, you get data discrepancies, billing disputes, and unrecognised revenue.

Credits and usage tracking: roll-over credits or usage drawdowns create a good user experience. But that upstream tracking is the foundation of your revenue waterfall. Gaps in how credits are logged compound silently until your financial statements no longer match reality.

Customer experience and accounting accuracy are two sides of the same question: what was consumed, when, and under what terms. Design for the user experience without anchoring it in the data model and you'll eventually pay a large manual operational tax.

Three takeaways

Scalability can't be retrofitted. True scale means infrastructure that holds across engineering velocity, regulatory compliance, and financial accuracy at the same time.

1. Speed needs to last beyond launch:
   The real test is whether a company can keep moving fast once volumes grow, pricing changes, regulators ask questions, and finance needs to close the books.

2. A strong data foundation is the product:
   A usage event, invoice, payment, refund, revenue schedule, and regulatory report may serve different teams, but they come from the same commercial reality. Disconnected systems turn every change into reconciliation work.

3. The best growth features create the hardest operational complexity:
   Discounts, credits, usage-based pricing, subscription pauses: good for conversion and retention, expensive for accounting, billing, and compliance. Strong infrastructure makes that complexity manageable rather than invisible until it isn't.

For anyone evaluating financial infrastructure, one question cuts through the noise:

"Can this system produce a complete, native, auditable trail from a single usage event to recognised revenue, for every pricing model you run, without your finance team doing manual work between billing and the ERP?"

Most vendors will say yes - so ask them to show you.