I just spent weeks in the Bay Area talking with engineering leaders at enterprise SaaS and AI companies, and one concern kept surfacing: entitlements infrastructure - the system tracking what customers can access and whether delivery matches what was sold. SOX Section 404 demands point-in-time entitlements, immutable audit trails, and independently reconcilable metering, entitlements, and billing - and AI makes this dramatically harder. With the IPO wave converging with credit-based pricing and ASC 606 tying entitlements directly to revenue recognition, homegrown duct-tape systems become a material weakness waiting to happen.
I just spent a few weeks in the Bay Area - HumanX in early April, then Stripe Sessions last week. I had dozens of conversations with engineering and platform leaders at large-scale Enterprise SaaS companies and AI frontier companies. I kept hearing the same thing, from people who don't normally talk to each other about this topic:
Entitlements.
Not pricing strategy. Not packaging experiments. Entitlements -the actual infrastructure that tracks what a customer is allowed to access, how much they've consumed, and whether what was delivered matches what was sold.
The reason? Many of these companies are either preparing for an IPO, recently went public, or are being held to public-company-grade scrutiny by late-stage investors. And it turns out there's a specific, technical requirement buried in SOX compliance that makes entitlements and credit management genuinely hard problems -not finance problems, but engineering problems.
Engineers and platform teams are about to get pulled into those conversations, and this information just might change the way you go about things.
What SOX actually requires (the part nobody warns you about)
The Sarbanes-Oxley Act (SOX) is usually framed as a finance and governance concern. Section 404 mandates that public companies maintain internal controls over financial reporting -and that those controls are independently audited.
Most engineering teams hear "SOX" and think of access controls, change management, audit logs on deploys. That's real, but it's the part everyone already knows about.
The part that catches companies off guard is fulfillment.
SOX auditors don't just verify that revenue was recognized correctly. They verify that what was sold matches what was provisioned -that the customer actually received access to the product, features, and capacity they paid for. This is called "evidence of delivery," and for software companies, it maps directly to entitlements.
Here's what that means in practice. An auditor will ask:
- Can you prove, for any customer at any point in time, what they were entitled to? Not what their Stripe subscription says. Not what their contract PDF says. What access and limits were actually enforced in your product at the moment of delivery.
- Can you prove that changes to entitlements are traceable? When a customer upgraded, downgraded, or had a promotional override applied -is there an immutable record of who changed what, when, and why?
- Can you demonstrate segregation between what was sold, what was metered, and what was billed? These three datasets need to be independently reconcilable. If they live in the same system, or worse, if entitlements are derived from billing data with no independent verification, that's a control gap.
For a traditional SaaS company with three plans and a handful of boolean feature flags, this is manageable. For an AI company with credit-based pricing, usage metering across multiple model tiers, and entitlements that change in real time based on consumption? This is an architecture problem.
Why AI makes this harder than anything that came before
Traditional SaaS entitlements are relatively static. A customer buys a Pro plan; they get access to features A, B, and C; those entitlements don't change until the subscription changes. The fulfillment proof is straightforward: here's the subscription record, here's the feature flag configuration, they match.
AI products break this model in several ways.
Entitlements are dynamic and consumption-dependent. A customer doesn't just "have access" to an AI feature -they have a budget of credits, tokens, or API calls that depletes in real time. The entitlement isn't a boolean; it's a moving number. Proving fulfillment means proving that at every point during a billing period, the customer's effective access matched their contractual allowance -and that enforcement happened before the expensive thing, not after.
The cost structure is inverted. In traditional SaaS, the marginal cost of serving one more customer on the same plan is near zero. In AI, every request has a real compute cost. A single uncontrolled API burst can cost thousands of dollars. This means entitlement enforcement isn't just a compliance concern -it's a margin concern. And SOX auditors will ask whether your revenue recognition accounts for the possibility of over-delivery (giving customers more than they paid for).
Product catalogs have high cardinality. AI companies often price differently across models, capabilities, and customer tiers. Enterprise customers get custom credit pools, volume discounts, and organizational hierarchies where credits are allocated across teams. The number of distinct entitlement configurations isn't three plans -it can be thousands of unique permutations. Every one of those needs to be auditable.
Agentic architectures multiply the problem. When a single user action triggers an agent that spawns sub-agents that make tool calls that each consume tokens -the relationship between "what the user did" and "what it cost" becomes deeply non-obvious. The entitlement system needs to track not just the front-door request but the full chain of consumption it generated.
The credit-model compliance gap
Here's a fact that surprised me when I started digging into it: there is limited precedent for public software companies that built their revenue model primarily on credits.
Snowflake is the most notable example. They IPO'd in 2020 with a consumption-based credit model -customers purchase Snowflake credits and consume them for compute time. Revenue is recognized as credits are consumed, not when they're purchased. Snowflake's former accounting leadership has spoken publicly about how reaching SOX-compliant processes at their scale took roughly two and a half to three years of intense work after going public. Their team had to build specialized accounting operations from scratch -dedicated units for revenue recognition, GL, equity, and tax -because vendor tools couldn't keep up with their consumption model.
AWS operates a consumption model too, but AWS wasn't a standalone IPO -it grew inside Amazon's existing public company infrastructure, with Amazon's existing SOX controls and audit history.
Now look at what's happening in 2026. OpenAI and Anthropic are both openly preparing for public offerings. These companies have credit-based revenue models at a scale that dwarfs Snowflake's at the time of its IPO. And they grew at a pace that left very little time to build audit-grade infrastructure along the way.
OpenAI's own engineering blog describes the system they built to solve this exact problem -what they call a "provably correct billing system." Their architecture deliberately separates three independent datasets: product usage events (what the user actually did), monetization events (what they charged for it), and balance updates (how credits were debited). They call this an intentional trade-off: they accept slightly delayed balance updates in exchange for provable correctness and the ability to independently audit, replay, and reconcile every layer. Every event carries a stable idempotency key so retries can never double-debit a balance. Balance updates are serialized per account so concurrent requests can't race.
That's what it takes. And OpenAI built it in-house, from scratch, because no vendor product solved the problem at their scale and specificity.
The problem isn't just for AI-native companies
This isn't exclusively an IPO-prep issue for frontier AI labs. It's equally relevant for established public SaaS companies that are adding AI features with credit-based pricing on top of their existing subscription models.
HubSpot, for example, now sells AI credits -packs of 1,000 for about $10/month, with auto-upgrade and overage options. Klaviyo has launched AI agents. Monday.com is embedding AI across its platform. These are public companies, already subject to SOX compliance, that are layering a fundamentally new revenue primitive (credits) onto infrastructure that was built for subscription billing.
Under ASC 606 -the revenue recognition standard that governs all of this -credits add real complexity. Revenue from credits can only be recognized when the performance obligation is fulfilled, which means when the credits are actually consumed. Purchased but unused credits sit as deferred revenue on the balance sheet. If a customer buys 10,000 credits and uses 6,000, you recognize revenue on 6,000. If they use zero, you recognize zero -even though cash is in hand.
This means the entitlement system isn't just an access control layer. It's a revenue recognition input. The data flowing through your entitlement and metering infrastructure directly feeds your financial statements. If that infrastructure is a collection of Redis counters, custom middleware, and billing system webhooks duct-taped together -you have a material weakness waiting to happen.
And the numbers suggest this is common. KPMG found that 23% of material weaknesses in IPO filings were attributed to inconsistent revenue recognition policies. Separately, 58% of IPOs reported material weaknesses in their initial filings. The most frequent root causes: manual processes, lack of systematic controls over transaction price allocation, and reliance on key-person knowledge rather than documented procedures.
Those are exactly the characteristics of homegrown entitlement and credit systems at fast-growing companies.
What SOX-ready entitlements infrastructure actually looks like
If you're an engineer or platform lead who's about to get asked "are our entitlements SOX-ready?" -here's what the auditors will be looking for, translated into engineering terms.
Immutable audit trail. Every entitlement change -whether triggered by a subscription event, a manual override, a promotional grant, or a credit allocation -needs to be recorded in an append-only log with timestamps, actor identity, and the before/after state. This isn't your application logs. It's a purpose-built audit trail that can be queried independently of your operational systems.
Separation of concerns between metering, entitlements, and billing. These three systems need to produce independently reconcilable datasets. If your billing system is also your source of truth for what customers can access, you have a single point of failure and a single point of audit risk. The metering layer says what happened. The entitlement layer says what was allowed. The billing layer says what was charged. All three need to agree, and you need to prove it.
Deterministic, reproducible enforcement. Given the same inputs (subscription state, usage data, credit balance), your entitlement engine should produce the same access decision every time. If enforcement logic lives in application code scattered across microservices, with different teams implementing rate limits differently, that's not reproducible -and an auditor will flag it.
Point-in-time reconstruction. You need to be able to answer: "What was Customer X entitled to on March 15th at 2:00 PM?" Not approximately. Not "whatever their current plan is." The exact entitlements that were active at that moment, including any overrides, promotional grants, or credit adjustments.
Controlled change management. Changes to entitlement logic -the rules that determine what access a given plan or credit balance confers -need to go through documented, approved processes. If a product manager can change a plan's feature set and it instantly affects all customers' entitlements with no review trail, that's a control gap.
The urgency factor
The timing isn't random. Three things are converging:
First, the AI IPO wave. OpenAI, Anthropic, and others are moving toward public markets. The financial scrutiny that comes with S-1 filings and SOX compliance is forcing these companies to look hard at infrastructure they built for speed, not auditability.
Second, public SaaS companies are adopting credits. What started as an AI-native pricing model is spreading to established platforms. Every company that adds credit-based AI features inherits the compliance complexity that comes with consumption-based revenue recognition.
Third, the scale of AI usage makes "good enough" infrastructure not good enough. When you're managing billions of API calls and real-time credit balances across enterprise customers with complex org hierarchies -the duct-tape solutions that worked at Series B don't survive an audit at the scale these companies operate.
Teams that start thinking about this early tend to have more room to adapt and avoid last-minute fixes. Others may only confront these gaps when external pressure, like an audit, forces the issue.
