Last month in Forbes Technology Council, Josh Dunham of Reveel made the case that dynamic pricing is the new normal. Annual rate increases are giving way to continuous adjustments. UPS and FedEx now layer surcharges that vary by ZIP code and time of year. Netflix raises prices around major content launches. Sports tickets shift by opponent and weather. Uber sets fares in real time. His advice: invest in real-time analytics, detect changes the moment they happen, forecast their impact.
He is right. Buyers need that visibility. But that solves only one half of the problem.
The other half is what happens to the invoice itself.
When prices stand still, an invoice is a list of items at known rates. Either side can reproduce the math. Disputes are about counting, not about price.
When prices move continuously, the invoice becomes something different. The number on each line is the result of conditions that existed at one specific moment. A surcharge that was active. A tier the customer just crossed. A rate that ticked up between 2:14 and 2:17 PM on a Tuesday. By the time the bill arrives, the conditions that produced it have moved on. Reconstructing them requires reproducing a system that is no longer running the way it was when the line item was computed.
This isn't a billing accuracy problem. It is a transparency problem. The bill might be exactly correct. The buyer simply has no way to confirm it.
What this looks like to anyone who has stood at a hotel front desk
You check out on a Sunday morning. The clerk hands you a folio with charges from four nights of stay. A $17 movie. A $12 water. A $42 "destination fee" you don't remember being explained at check-in. You ask why. The clerk says the system charged it. You ask which system, why $42, why on Tuesday and not Thursday. The clerk has no answer. There is a system. The system has the number. You either pay or you stand at the desk for twenty minutes while a line forms behind you.
This is the universal experience of a self-attested bill. The seller's system produces a number. You either accept the number or you give up. There is no third place to look. The seller's word is the only record, and the seller's word is what you are being asked to verify.
For a $317 hotel folio this is annoying. For a $217,000 enterprise invoice it is unworkable.
Three forces are accelerating this, fast
The first is dynamic pricing. The Forbes piece names the trajectory. Pricing is moving from once-a-year to continuous. The average enterprise SaaS bill in 2026 is composed of dozens of line items, each priced under conditions that have already moved by the time the invoice is sent. 78% of IT leaders report seeing unexpected charges from consumption-based pricing on bills last year. Most of them cannot independently verify whether the charge was correct.
The second is volume. The number of metered events behind a single enterprise contract has grown by orders of magnitude in five years. A single AI inference contract can include hundreds of millions of API calls in a month. No human is reviewing a bill that long. Reconciliation has moved from "two people checking the math" to "a system flagging anomalies on bills nobody is reading." The trust gap that used to be visible in disputes is now invisible in approvals.
The third is the one nobody is naming yet. Software is increasingly the buyer.
AI agents are already negotiating contracts, approving invoices, and triggering renewals on behalf of organizations. Procurement systems are filtering bills and approving them automatically. Compute orchestrators are selecting model providers in real time based on price and latency, then receiving and paying their bills without human review. The volume of machine-generated invoices being read by other machines is growing. By the end of this decade, it will be the dominant mode of commerce in software, in AI, and across any high-frequency service.
This is the part current infrastructure was never designed for.
What software-to-software commerce actually requires
When a human reads an invoice, they can absorb a small amount of opacity. They can call a rep. They can email an account manager. They can wait three days for an answer. The relationship is a buffer.
When software reads an invoice, there is no buffer. Either the invoice is independently verifiable, or the receiving system has to trust it on faith. Trusting on faith does not scale to billions of transactions per day. Calling a rep is not in the API.
This is the shift recordation names. A category in which the bill is not the only record of what happened. Alongside the bill, there is an independent account of the events the bill was computed from. The buyer can check the account without asking the seller. The seller can defend the bill by pointing at the account. Both sides reference the same source. Neither side controls it.
The closest precedent in existing infrastructure is post-trade reporting in financial markets. When two firms transact on an exchange, the trade happens through whatever venue they chose. The trade then gets reported to a neutral layer that publishes it as a verified record. The trade is checkable by either party, by regulators, and by anyone with standing. The reporting layer does not replace the exchange. The exchange still matches buyers and sellers. The reporting layer makes what happened on the exchange independently confirmable, by anyone, after the fact. Without it, modern capital markets do not function at the volumes they currently operate at. Recordation borrows the shape, not the audience. Unlike the tape, the record stays between the two parties; what is checkable more widely is only the proof that it has not changed.
Usage-based commerce is approaching the same threshold. The bill still needs to get produced. The metering still needs to happen. The pricing engine still needs to compute the number. What is missing is the layer alongside that produces a verified record both sides can check. That layer is what recordation is.
Pricing keeps moving in the same direction
The trajectory does not stop at continuous pricing. The next step is auction-based pricing for usage, in real time, between machines.
The pieces are already in place. AWS Spot pricing fluctuates by region, instance type, and minute, and the buyers are mostly automated systems making procurement decisions on price-availability tradeoffs without a human in the loop. Programmatic ad bidding has done this for two decades, resolving billions of auctions per day in under 100 milliseconds between systems that have never spoken to each other and never will. Inference routing platforms like OpenRouter and Together AI are running early versions of price-and-availability routing across model providers. The conditions that pushed display advertising and cloud compute toward real-time auctions, constrained supply, variable demand, and machine participants on both sides, are now visible across compute, inference, bandwidth, and any other usage-based category where supply is uneven and demand is volatile. Real-time auction pricing is the natural endpoint of every shift currently underway. It is two to three years out for the most volume-sensitive categories, less for some.
This is where the transparency problem becomes structural rather than annoying. In a static rate card, the rates are knowable in advance. In a continuous-pricing model, the rates are at least logged, even if reconstructing them is painful. In a real-time auction model, the rate that was active for one specific request at one specific millisecond was the result of a price discovery that happened among multiple parties under conditions that existed only in that moment. The number on the eventual bill is the outcome of thousands of auctions per second, none of which the buyer can reconstruct from anywhere except the seller's logs. A human procurement team cannot meaningfully audit that. Even a buyer-side analytics system cannot meaningfully audit that, because the conditions of each auction are gone before the next one runs.
The only thing that makes real-time auction pricing actually work as a market is a verified record produced at the moment of each auction outcome. Without it, the buyer-side software has no way to confirm what it is being charged for. Procurement systems are designed to fail closed when they cannot confirm what they are paying for. Either the auction comes with verification built in, or buyer-side software refuses to participate at scale, or it overpays defensively and the auction's efficiency collapses. Recordation is not a feature that gets added to real-time auction pricing later. It is the precondition that lets real-time auction pricing function at all.
How a category gets built
A useful precedent for what is happening here is observability.
Twenty years ago, software ran in production with logs, basic monitoring, and the application's own diagnostic output. Each was a separate tool. Each was useful. None of them, individually, answered the question every operator actually had: what is my system doing right now, and is it healthy?
The category that filled that gap got named observability. It did not replace logging or monitoring. It sat above them, integrated their outputs, and produced a layer of insight neither could produce on its own. Today, no serious operator would consider running production software without observability. It is a budget line. It is a procurement category. It is a question buyers ask vendors before signing.
Recordation is the same kind of move. Metering is real. Rating is real. Invoicing is real. Each is essential. None of them, individually, produces a record both buyer and seller can verify without involving each other. Recordation names the layer that does. It sits alongside everything that already exists and does not replace any of it.
The systems that compute the bill keep doing what they do well, which is producing accurate numbers under increasingly complex pricing conditions. Recordation adds the property they cannot structurally provide on their own, which is independence. The bill becomes more defensible because there is now a record alongside it that both sides can check.
Observability did not become infrastructure by being adopted everywhere. It became infrastructure by becoming the way a particular question got answered. Buyers stopped asking how to answer the question and started asking which tool to use. That is what "category becomes infrastructure" actually means.
Recordation is on the same path. The difference worth naming is that it does not need to shed its name to get there. The word describes the act exactly: a claim recorded, fixed at the moment of the event, available to either side without involving the other. When recordation becomes infrastructure, the word stays, because the word names what the work is.
What changes when this layer is in place
Enterprise procurement stops requiring the buyer to take the seller's word on a number they cannot reproduce. The bill arrives with a verified record attached, and the record is what gets checked.
AI vendors who today struggle to sell into skeptical procurement organizations get a different conversation. The procurement team can verify the bill without the vendor's help. The vendor's billing accuracy stops being something the buyer has to accept on faith.
Disagreements between buyer and seller stop being adversarial. Both sides reference the same record. The conversation becomes a comparison, not a confrontation. The dispute as a multi-week, multi-team escalation effectively ends.
Software paying software becomes possible at scale. AI agents transact, the bill arrives with a verified record attached, the receiving system checks the record before approving, the conversation resolves in milliseconds without a human in the loop. This is the architecture autonomous commerce needs to function at volume. It does not exist yet. It is being built now.
The systems that already produce bills get more valuable, not less. Their invoices ship with verification attached. The single biggest critique of usage-based billing for the past decade, that the seller's books are the only record, stops being true. Buyers trust the bills more. Sellers defend them less. Both sides spend less time in reconciliation and more time in the business.
The end of the billing dispute is the beginning of something larger
The billing dispute, as we have known it, ends because the conditions that produced it stop existing. The seller no longer holds the only record. The buyer no longer has to ask permission to check. The black box opens.
That is the immediate, concrete value. It is also the smaller half of what recordation makes possible. The larger half is the architecture it enables underneath. Software paying software at scale. Procurement that does not require trust. Cross-jurisdictional commerce where neither side trusts the other's books and both sides reference the same record. Regulatory environments where self-attestation falls below the bar. Business models that depend on machine-paced verification and are not possible without it.
Dynamic pricing is the leading indicator. Machine commerce is the inevitable destination. Recordation is the layer that makes the destination reachable.
PacSpace is what gets built first. Verification is what gets built around it.