RevOps Review
Articles

Why AI agents need a unified revenue foundation

Why AI agents need a unified revenue foundation

Why AI agents need a unified revenue foundation

Tina Kung, CTO and Founder, Nue

Tina Kung, CTO and Founder, Nue

Copy to clipboard

Ask an agent to add 50 seats to a customer's plan and it will add the seats. What it can't know on its own is that expanding a subscription is rarely one action. You co-term the new seats to the existing end date, prorate the charge, follow it through to the order and the billing schedule, burn down the credits, and roll it into ARR and the books, in the right order.

 

An agent operating on a fragmented revenue stack inherits every gap in it. That is the problem Nue is built to solve. 

 

Every company I supported at Salesforce, Zuora, and Oracle hit the same wall. They had integrated quoting and billing, sometimes elegantly, and the two systems still didn't agree. They never would. You can sync two systems by hand. You cannot make them agree by design. Everyone I worked with knew this was a problem, but no one solved it, because the fix wasn’t a feature you could add. It meant rebuilding the foundation.

 

Teams kept layering translation on top: converting one object model into another, reconciling prorations down to the cent, or rebuilding the same product once in the CRM and again in billing. Every mismatch became a manual exception, and those exceptions piled onto finance at the close, where periods that should have stayed closed got reopened instead.

 

When we founded Nue, we decided not to simply connect the existing systems. We built one model underneath all of them. A quote and an order are not two records that have to be synchronized. They are two views of the same deal, the promise and the fulfillment, and they should run on the same data.

 

That decision gave us three principles we still build on: guardrails by design, one revenue data model, and hybrid by default.

 

Guardrails by design: An agent is only as good as the controls around it

Generating logic is cheap now. Knowing the consequences of a revenue action is the hard part. 

 

That kind of judgment cannot sit in a prompt. Permissions, policy boundaries, audit trails, and finance controls have to live in the model itself. A fragmented stack has nowhere central to put them, so every system enforces its own version of the rules, or none does.

 

One model gives the guardrails a single home. This is what agentic revenue architecture means in practice: one model running the whole flow, with the controls that let people and agents act on it safely. That is the only way an agent can act on revenue without doing damage.

One revenue data model: A single handoff between quote and order

The quote is the last act of CPQ, and the order is the first act of billing and the start of the customer relationship. They meet at one handoff, the point where a closed deal becomes something to fulfill and charge for. Splitting that handoff across two systems means building the same products, pricing, and subscriptions twice, once under each data model, and then keeping the two copies in agreement by hand.

 

Legacy quote-to-cash was always assembled from separate systems. CPQ had one model, billing had another, usage was a third, and provisioning, fulfillment, and finance reporting each added their own. Keeping them synchronized consumed an enormous amount of energy, because it was never only products and pricing that had to match. Every transaction had to match too, or the chart of accounts came out a mess.

 

On a unified data model, products, pricing, and transactions live in one place. They are not rebuilt for each system and reconciled by hand afterward. Data flows from quote to order to billing to the books without translation, and it lands in a clean chart of accounts.

 

Reuniting the quote and the order is what lets revenue move from closed-won all the way to a financial statement without anyone stitching it back together.

Hybrid by default: No company at scale runs a single motion

Past systems were built on the assumption that a company would choose one way to sell and never need another. But when a business runs several motions at once, any architecture built for a single motion turns the rest into workarounds. We built for hybrid from the start, in three senses.

 

The same deal can close direct, through self-service, or through a partner, so the architecture has to treat all three channels as native rather than as exceptions.

 

Subscription, consumption, commits, credits, and outcome-based pricing all run on the same foundation, because the architecture was never built to favor one over another.

 

And people and agents increasingly work the same deals together. In certain scenarios today, agents handle the mechanical work, like creating a quote when usage crosses a threshold, so people can spend their time on judgment and on closing.

 

When hybrid is the foundation rather than a feature, adding a channel, mixing in a new revenue model, or handing work to an agent is a normal operation instead of a re-platforming. A system built around a single motion pushes the business back into spreadsheets the moment it tries something new.

The architecture is the strategy

Legacy systems were built for a slower world, one where pricing changed once a year and a company ran a single motion. That world is gone. On a fragmented architecture, every new model, channel, or agent becomes an integration project, and pricing turns into a liability instead of a lever.

 

It changes what a revenue team can do. Revenue moves from quote to cash without translation. Finance can trust the close. The company can launch a new revenue model, open a new channel, or put an agent to work without bracing for what might break.

 

We built Nue this way on purpose. Putting a quote and an order on one model was never just a technical decision. That architecture is the strategy.

Takeaways

Quoting and billing were built as separate systems that were never designed to agree, and no amount of integration fixes that. The problem can only be solved at the foundation, which is why Nue built one unified revenue architecture underneath quoting, billing, and revenue recognition rather than connecting existing systems.

  • Pricing, quoting, billing, and revenue recognition share a single data model, so a deal flows from quote to financial statement without translation and finance closes against a clean chart of accounts.
  • Permissions, policy boundaries, audit trails, and finance controls live in the model itself, which is what lets an AI agent act on revenue safely rather than executing a destructive action like canceling an invoice without the steps it requires.
  • The architecture treats every sales channel, every revenue model, and every mix of human and AI work as native, so a business can run multiple motions at once without forcing the rest into workarounds.

Putting a quote and an order on the same model is a technical decision and a strategic one at the same time: it is what lets a company launch new models, channels, and agents without rebuilding its foundation.

 


 

Watch the full conversation: Tina Kung, Mark Walker, and Ashley Deibert on agentic revenue architecture.