As usage-based billing matures, we’re seeing platforms take on more workflows, orchestration, and business intelligence. At the heart of that expanding role and increasing complexity is something very simple that has always made the category valuable: billing brings revenue, product, and customer data together into a meaningful story that teams can use to make decisions.
And that's only gotten more true as AI has taken hold. Increasingly, the teams we speak to are using agents and AI to manage finance workflows, inform decisions, and increase their velocity. And they're using billing data to power it.
At Orb, we’ve always seen value in maintaining and surfacing this data. It’s a major reason we built our platform to preserve as much granular usage data as possible, rather than aggregate it away. Keeping that detail gives teams the flexibility to ask new questions and understand the activity behind the numbers.
That value is coming up more often in our conversations with customers and prospects. Questions about data exports, MCPs, and integrations reflect a growing interest in using billing data in reports, tools, and agent workflows across the business. Teams want to build on the connection between product activity, customer agreements, and revenue that already exists in the billing platform.
As more of the business works from this data, maintaining it as a source of truth becomes a bigger responsibility. Teams need to know where a number came from, how current it is, and who changed the pricing or contract terms behind it. They also need to understand how their own changes will affect customers and the other workflows that depend on the platform.
Beyond billing: How teams are applying product + revenue data
The applications range from everyday financial reporting and customer conversations to emerging agent workflows:
- Finance and BI teams use warehouse exports to report on revenue, reconcile payments, analyze discounts, and track credit consumption.
- Sales and customer success teams use usage, invoice history, and credit balances to prepare for renewals and spot expansion opportunities.
- Product teams use billing data in customer dashboards to show remaining credits, explain charges, and track spending against commitments.
- As agents take on more work, they will need this context to recommend plans, check balances, and propose changes for approval.
What makes a source of truth hard to maintain?
Anyone who has worked on keeping a CRM clean will recognize the problem. Calling something a source of truth comes with ongoing work: removing duplicates, assigning owners, checking integrations, and helping people understand how to use the data. Billing platforms face many of the same challenges.
1. Sprawl
Sprawl can happen across tools or within a single platform. A price gets copied across several plans. A discount rule lives partly in the CRM, partly in billing, and partly in an engineering service. A warehouse report uses a calculation that has drifted from the one used to generate invoices.
Eventually, someone asks which version is right, and answering takes a fair amount of investigation.
Reducing that work starts with defining shared prices and rules in one place, then reusing them wherever they are needed. Downstream teams should be able to reference the original definition and understand how their reports relate to it.
2. Unclear ownership
Pricing often involves product, finance, sales, engineering, and customer success. Each team brings useful context, but responsibility for an individual change can get lost between them.
When someone has a question about a price, they should be able to find out who changed it, which customers it applied to, and who can explain the decision. Otherwise, they are left searching Slack or hoping someone remembers the conversation.
3. Uncertainty about the data and the effects of a change
Billing changes can affect invoices, revenue recognition, credit balances, customer dashboards, collections, accounting systems, and data exports. People need a reasonable understanding of those effects before they are comfortable making a change.
Describing a migration to a new plan version, one participant in a pricing research call put it this way: “I’m gonna press this button and hope nothing bad happens.” Price changes often feel risky because their effects can be hard to predict across a complex billing system.
What we can learn from software development
Software teams have a lot of experience managing frequent changes to systems that other people depend on. Some of their everyday practices are useful models for pricing.
Version control records how code changed over time. A diff shows exactly what changed between two versions, so a reviewer can look at the specific edits rather than reread the whole codebase. Code review gives someone else a chance to check the work and ask questions before it goes live.
When a developer needs to understand an earlier change, git blame shows the commit and author responsible for the last change to each line. That gives them a starting point for finding the context and asking questions. Pricing teams need the same ability to trace a change back to the person who made it.
Teams also run tests to check that a change works as intended and has not broken existing behavior. They can try it in a separate environment before putting it in front of customers. Once it is live, logs and monitoring help them see whether it is behaving as expected, and a rollback process gives them a way to return to an earlier version if needed.
These practices help people make changes more confidently because they can check their work and recover from mistakes. Pricing teams would benefit from the same kind of support.
Take a price increase. Before applying it, the team should be able to see which prices are changing, who is responsible, and how the change would affect actual customers and their invoices. They should be able to ask someone to review those effects, select the customers who will move to the new price, and choose when that happens.
Afterward, they need a record of the migration and a way to check the resulting invoices, balances, and reports. If something is wrong, they need to understand how to correct it while preserving the history.
That gives teams a practical way to keep pricing moving without making every update an exercise in tracking down possible side effects.
How this shapes what we build at Orb
These requirements show up in several parts of Orb: how prices are organized, how changes are recorded, and how teams review and apply changes to customers.
A shared price catalog
Recently, we launched Pricebook. It lets teams define a price once and reuse it across plans. That reduces the number of copies they have to maintain and the chances that those copies drift apart.
Sharing a price definition and deciding when to change a customer’s pricing are separate decisions. Teams can organize their prices centrally while keeping control over which customers move to new pricing and when.
A clear record of who changed what
In software development, git_blame shows who last changed each line of code. The same idea applies to pricing: when someone looks at a price, they should be able to see what changed and who made the change.
Pricebook brings that ownership lens to pricing history. If a number looks unexpected or someone needs to understand how a decision was implemented, they can find the person behind the change and ask for context.
A way to review changes before applying them
Orb’s diff-based engine compares the current billing state with the result of a proposed change. It can calculate what would happen without applying the change immediately.
Pending changes use that capability to let teams prepare a subscription change and inspect the resulting subscription and invoice previews. They can then apply it once payment, validation, or approval is complete. Pending subscriptions stay out of data exports, so those draft subscriptions do not enter reporting before they are confirmed. Read about pending changes and the diff-based billing engine.
Just as a developer asks a teammate to review code before it ships, a pricing team can have someone check the proposed terms and invoice impact before applying the change.
Versioned pricing and explicit customer migrations
In Orb, changing a plan’s prices means creating a new version. The earlier version stays intact, and teams can see which prices were added, removed, or changed in the new one. This preserves the pricing history they need to understand how a customer was billed, even after the business has moved on to a different pricing model.
Publishing a version and moving existing customers onto it are separate steps. Making a version the default determines the pricing used for new subscriptions; existing subscriptions stay on their current versions until they are explicitly migrated. That gives teams room to honor existing agreements, keep customers on older pricing, or introduce new terms at renewal.
When a team is ready to migrate customers, it can select the subscriptions to include, review how many will be affected, and preview the invoice impact for individual customers. It can also choose when the migration takes effect: immediately, on a specific date, or aligned with each customer’s billing term. Those choices let teams plan a rollout around their customer commitments and check the consequences before proceeding. Read about migration previews and timing.
That history remains useful downstream. Orb represents each subscription as a timeline of prices with start and end dates, so teams can trace which terms applied at a particular point in time. For someone reconciling a financial report or explaining an older invoice, that provides the historical context behind the number they are looking at.
What teams should be able to expect
As more workflows depend on billing data, the people using it need to be able to follow a number back to its source, find the person responsible for a change, and understand what an update will affect. That applies whether they are building a financial report, answering a customer question, or giving an agent permission to act.
The software development model gives us a useful place to start. Shared definitions, clear change history, previews, review, and deliberate rollouts can make pricing easier to manage as more people and systems depend on it.
For billing platforms, supporting those habits is becoming part of the job. Teams should be able to keep changing how they price and sell their products with a clear understanding of what they are changing and how it will affect their customers.
