Most planning models explain last quarter. Ours change the next one.

Explaining the past is table stakes. The model earns its cost on the questions that face forward:

Every one of those is a revenue decision, a time decision, or a risk decision. A model that can only reconcile history answers none of them. So we build the diagnostic layer to be instant, because its real job is to get out of the way.

The fashionable fix is a driver model: blended take rate times volume, adjusted for product mix. Better than a straight line. It also can't see inside a contract. Real fintech contracts have tiered pricing that reprices at volume thresholds (retroactive or prospective tiers, and the difference is material at every threshold crossing), contracted minimums that floor revenue when volume dips, overages above committed volume, item-level pricing that differs by product on the same agreement, and scheduled repricing. A blended-rate model treats all of that as one number and hopes it holds still.

So we build it the other way up.

Rate stops being an assumption and becomes an output. And here is where it turns forward-looking, because rate also becomes an input once or twice a year, when you decide it. A planned increase across the book. A renegotiation with your largest client. A repricing at renewal. In this architecture those are decisions you can test before you announce them: model the increase first and see which clients cross into new tiers, which minimums quietly neutralize it, and what the action is actually worth, name by name. Then, after it ships, the actuals show what landed, and when part of the book refuses the increase at renewal, you know which contracts rather than just watching the blended rate come in soft.

That's the pattern for the whole page. The backward question (what happened to rate?) and the forward question (what should we do to rate?) run through the same engine. Answer the first one instantly and the meeting gets to spend its time on the second.

The model we build tracks signed contracts as activation cohorts with time-to-live by segment, slippage visible by week, and capacity modeled as the constraint it is. Which means you can ask it forward questions: if we add two implementers to the segment with the fastest-converting backlog, how much contracted revenue moves into this fiscal year? That's a decision with a number attached, and it's usually a better use of the next hire.

One more opinion while we're here. Probability-weighting pipeline is the wrong tool for veto-gated sales cycles. A 70% weighted bank deal isn't 70% likely; it's binary and sitting in a security review. Stage-gate tracking through the diligence phases tells you where to intervene. A blended probability tells you a comfortable lie.

Fintech pays sellers in ways plain SaaS never has to: roughly half the usage commission at signing on estimated consumption with the balance settled on actuals, clawbacks when booked TPV never materializes, and crediting rules for partner-sourced deals through FIS, Fiserv, Jack Henry, ISVs, and sponsor banks. We build engines that handle all of it.

Get the engine right and comp stops being a payout calculator and becomes a steering wheel. When you want a product pushed, you can model the crediting change, see what it costs, and ship it mid-year instead of waiting for the annual plan. Mid-year comp changes are where credibility with the field usually goes to die; they survive when you can show the math.

Margin by line is where several of those decisions get made. The Visa and Mastercard settlement approved in June 2026 takes roughly 10 basis points out of credit interchange over five years, a scheduled reminder that take rates compress. Decompose gross margin into interchange, network fees, processing costs, and sponsor bank fees, which have risen noticeably since Synapse collapsed and banks repriced program risk, and the model can tell you which revenue is worth growing, where a pricing action defends margin rather than volume, and which product push actually drops through to gross profit. For payments businesses we'd compute Rule of 40 on recurring gross profit growth rather than revenue growth, because growing pass-through-heavy revenue at thin margin is not the same achievement as growing software revenue.

Decisions are only as good as the numbers underneath, which is where rev rec comes in. One position up front: a planning model forecasts revenue recognition, it does not perform it. Your 10-K runs on the ERP subledger, NetSuite ARM or Zuora RevPro, and auditors accept the subledger, not a planning tool. So we build the forecast rev rec to tie to that subledger, same waterfall logic, same treatment, so a decision modeled today reconciles to the number reported later and your controller stops rebuilding the bridge every close.

The fintech-specific pieces are what we actually build for:

Everything above, end to end: the contract engine with its volume layer, booked-to-live activation tracking with capacity as a lever, the commission engine, float and rate scenarios, margin by revenue line, all tied to the subledger.

And for acquirers, the work we're proudest of. Purchase accounting resets acquired ARR, deferred revenue haircuts change what recognizes when, and customer lists across entities hide duplicates until consolidation surfaces them. A model built for this gives you the structure on day one, so integration becomes a data exercise measured in weeks rather than a rebuild measured in quarters, and you can evaluate the next deal with the model instead of promising the board you'll figure out integration later. For sponsor-owned companies we build the reporting that ownership demands: sponsor packages, lender covenant tracking, multi-entity consolidation.