Optimality builds execution intelligence software for engineering and capital project teams. They serve major energy companies and global capital project firms. The platform connects plans, deliverables, and decisions across large, multi-disciplinary projects so teams can surface risk before it compounds.

Simon Wright is the CEO and Co-Founder of Optimality. He was responsible for making the company's billing model work for enterprise customers. For a period, it was not working.

"We went from twelve days of manual reconciliation to a two-day close. But the bigger shift is that finance now has a live deferred revenue balance at any point in the month, not a number we reconstruct at period end and trust for a week"

said Simon Wright, CEO and Co-Founder.

Three billing components meant revenue recognition had to be manually rebuilt at every close

Every Optimality enterprise contract carries three separate billable components: a platform subscription, an AI compute pack billed by token throughput, and a knowledge base storage capacity fee.

Under ASC 606, each is a distinct performance obligation with its own recognition schedule. The platform subscription recognizes straight-line over the contract term. The storage capacity fee also recognizes straight-line, but separately. The AI compute pack recognizes as compute is consumed, which means the recognized balance moves with actual token usage across the period rather than tracking a fixed monthly rate.

With three components recognizing under three different treatments on every enterprise contract, closing the period meant the finance team had to pull platform billing records, match compute usage against contracted pack limits, reconcile storage consumption, and manually separate what had been earned from what remained deferred, across every account, every month.

There was no system that could hold this level of contract structure and apply the recognition rules automatically. Every close was a manual reconstruction exercise that grew longer as the enterprise book expanded.

Annual enterprise contracts created a deferred revenue balance that could not be tracked in real time

Optimality's enterprise customers often paid annually upfront. Under ASC 606, cash received upfront posts to the balance sheet as deferred revenue and releases as each performance obligation is satisfied.

For contracts with three components, that meant three separate deferred balances per customer, each releasing on its own schedule. The platform and storage fees were released straight-line. The compute fee is released with usage.

Because no system tracked this in real time, the deferred-to-recognized waterfall had to be rebuilt from source data at the end of every period. The finance team worked back through each contract, the usage records, and prior-period releases to reconstruct the split by hand.

As the enterprise book grew, so did the time required. What should have been a one-day exercise stretched to twelve days. Invoices that should have gone out on the first of the month were consistently late, and DSO was extending before customers ever saw a bill.

Enterprise customers had no audit trail every documentation request meant rebuilding from scratch

When enterprise procurement teams requested documentation behind an invoice line, the finance team had to reconstruct the audit trail from scratch.

Which contract clause drove the platform fee recognition? Which token events contributed to the compute line for that period? Which capacity tier was in effect for the storage fee? None of these answers existed in one place, and none were generated automatically when the invoice was produced.

Every documentation request meant going back to the source data, identifying the relevant records, and rebuilding the audit trail after the fact. For a growing enterprise book with sophisticated procurement teams, this was not a process that could scale.

"We had three separate components on every enterprise contract, the platform fee, the compute, and the storage. Each one is recognized differently under ASC 606. Tracking that manually across a growing customer book at every close was not something one person could sustain. The close was consistently late, and when a customer came back with questions on an invoice, we were rebuilding the same calculation we had already done once that month"

said Simon Wright, CEO and Co-Founder.