Usage-based billing: consumption is metered hourly, the invoice arrives once

A software contract signed in January reaches finance in October with a number nobody approved. There was no calculation error. There was consumption.

In the usage-based billing model the buyer pays for what it consumes, and on the seller's side that consumption is reported to the marketplace hour by hour. In this model, which AWS Marketplace names SaaS subscriptions, each license, each account and each usage dimension become a line with a date and a timestamp. On the buyer's side, what arrives automatically is the invoice, and it follows the vendor's cycle or the channel's, not the meter's clock; the interval between one invoice and the next depends on what the vendor exposes in the product.

The person who signs an international software contract is a controller, a procurement manager or an IT leader, and answers for that budget line. The distance between the two clocks decides whether the number fits inside the month. The question that organizes everything after it is not how much the license costs. It is who measures, how often, and what arrives in the middle of the month.

What changes in usage-based billing when measuring stops being expensive

The premise is simple: integrating metering always demanded engineering from the vendor. On October 13, 2026, AWS Marketplace published a metering skill that generates the integration code inside the IDE. The effect for the buyer is not a lower price. The plausible reading is more vendors with the meter switched on.

The skill arrives through the AWS MCP Server and guides the construction of the metering integration: it surveys the product's usage dimensions, recommends an API approach and delivers the code with the AWS SAM templates, which the vendor then reviews and deploys. The skill only deploys directly to a Limited listing. In a published product, the code goes back into the vendor's own pipeline.

What falls is the cost of measuring. The price of the software does not move because of it.

And measuring is not a neutral act. The meter is code the vendor writes, operates and corrects, and the invoice is the output of that code after the marketplace consolidates the reporting. Granularity of the data and trust in the data are two different things.

The two pricing models capture growth at different moments

The post names two models, and they are distinct. In a SaaS contract, growth inside the term is captured by a new offer and an amendment at renewal. In SaaS subscriptions the buyer pays for what it consumes, and growth can appear in the vendor's revenue reporting within the hour.

What matters to whoever approves the budget is the instrument. In the first model, and as long as there is no metered rate above the commitment, growth becomes an event with a date, a proposal and a signature. In the second, the spend happens in usage and reaches the approver at the close of the billing cycle, not at the moment of the decision, and the complete comparison between the two sits in SaaS pricing models in a cloud marketplace.

Who measures, and how often

The skill deploys two CloudFormation stacks: the agreement-events stack listens to the marketplace, and the metering stack turns usage into an hourly line along two paths, registration and metering. The vendor's application writes the lines. The write is not hourly. The aggregation and the send are.

The agreement-events stack carries the EventBridge rule on aws.agreement-marketplace, an SQS queue and a DynamoDB table with one record per agreement and the licenseArn that metering requires. On the registration path, an API Gateway endpoint receives the token when the buyer configures the account, and a Lambda exchanges that token for customer identifiers through ResolveCustomer.

That endpoint is the only point in the design where the buyer appears. The rest belongs to the vendor: one message per license and per hour enters a queue, the aggregation adds up the lines by license, buyer account, dimension and hour, and the last function sends them in batches through BatchMeterUsage.

This is where the source stops describing the buyer. What it documents on the buying side ends at the registration page. The hourly granularity exists on the selling side. In a direct contract, what the buyer can see inside the month depends on what the vendor exposes in the product; in a purchase invoiced by the channel, the metered quantity enters billing through another route. What is missing is a clause, not a measurement: internal measurement gives a dispute its backing, but on its own it has nothing to compare against.

What the skill does not do, and why that matters to a buyer

The part the skill does not do is the part that decides the quality of the number. The vendor's application is what writes the usage lines, from the accounts where the workload runs. Building that input is the vendor's work, and it defines whether the invoice describes consumption or merely resembles it.

The source post says two things that, read together, draw the buyer's position: putting usage into the system is the part the seller builds, and the generated code must be reviewed against the vendor's own security and compliance requirements before it goes to production.

That is not an accusation. It is an information asymmetry.

Under-reporting does not give money back. It generates a retroactive correction with no contractual cap, or a supplementary invoice after the cycle has closed, over a number already provisioned. Over-reporting creates a dispute the buyer only wins with its own data, measured on the same event and in the same dimension as the contract. The question stops being whether the vendor measures well. It becomes another one: what the vendor commits to showing when it measures wrong. That answer lives in the contract, not in the product.

From Step 1 to Step 4: the four questions before signing a consumption contract

Four questions separate a consumption contract the buyer controls from one the buyer discovers. Each has an answer that works and an answer that does not, and the difference is rarely in what the vendor promises. It sits in what the vendor accepts putting in writing.

The master list:

1. Which dimension the contract measures, and how it maps real usage.
2. How often the vendor reports, and what it returns to the buyer.
3. What happens inside the term if consumption grows.
4. What happens if the reporting fails or lags, and who absorbs the difference.

Step 1: the dimension measured. It sounds technical. It is the most practical of the four: active users, processing hours, API calls and traffic volume produce very different invoices over the same usage. Good answer: the dimension is an event the buyer can count on its own side, with the same criterion. Bad answer: a processing unit defined in the vendor's internal annex, which nobody on the buyer's side can reproduce.

Step 2: the frequency and the return. Good answer: a report in the same dimension and at the same frequency used for billing, delivered before the invoice, with a named dispute window, never shorter than the buyer's own closing cycle. Bad answer: the frequency exists as the vendor's internal obligation and the contract names nothing that reaches the buyer.

Step 3: the middle of the term. In a SaaS contract growth is captured by a new offer and an amendment at renewal, so the question is about notice, while in SaaS subscriptions it arrives through the invoice and the question is about a trigger, which is settled with a written limit, not with a renewal date. Good answer: the contract names a limit from which the vendor gives notice before consumption becomes a charge. Bad answer: silence until renewal, which is exactly the ground of the hidden risk at renewal.

Step 4: the reporting failure. Every meter fails. The contract has to say what happens next. Good answer: a resend rule, a retroactive correction window of one to two cycles, settled by credit rather than by an open supplementary invoice, and a definition of who absorbs the difference when the correction is not possible. Bad answer: "assessed case by case", which hands the vendor discretion over its own error.

The four answers, side by side:

And if the vendor refuses? Refusal is a possible branch, and the question only has consequence if the buyer knows what to do with it. Without a reporting clause, the buyer limits exposure through a written cap, prepayment or a commitment, and the risk it accepts acquires a value instead of staying unknown. Refusing is not a reason to walk away from the contract. It is a reason to sign knowing what was left out.

What to put on the buyer's side

On the buyer's side, SaaS consumption control starts before signature. A consumption contract calls for three things: a service order with the metering clause attached, the consumption history of prior cycles in the billed dimension, and a reporting clause that names format, periodicity and the dispute window.

Governance then becomes concrete: a budget per dimension, an alert before the overrun, and reconciliation between internal measurement and the invoice.

Part of that check is a spreadsheet, part is a tool. The Nexforce Marketplace description lists centralized subscription management, budget and renewal alerts, local payment with a nota fiscal in BRL and installments of up to 12x with a locked exchange rate. The cost reduction of up to 50% on international solutions comes from that contracting chain, not from a discount table. For the whole process, the SaaS procurement policy and reducing SaaS cost without renegotiating the contract complete the reading.

The verification is one meeting and one file: ask for the report of a closed cycle, in the format the clause promises, and compare it line by line with the invoice for that cycle. If the file does not exist, the clause is on paper, not in the process.

Two errors repeat in that check. The first is measuring the wrong dimension: the team tracks active users while the contract bills processing hours. The second is reconciling after the close, when the correction is already a credit negotiation. Both corrections are procedural: mirror the exact dimension of the contract in the internal dashboard, and reconcile before the close.

Frequently Asked Questions

Does the buyer receive the detailed hourly consumption from the vendor?

It depends on what the vendor exposes. The hourly granularity exists in the reporting the vendor sends to the marketplace, and it is not an automatic right of whoever buys. The contract can demand a report in the same dimension and at the same frequency used for billing, and that is what turns the data into a verifiable clause.

Does the reporting clause change anything in a SaaS contract?

It does, and not in order to check consumption on the monthly invoice. In that model the number that changes is the renewal number, and the new offer arrives with the volume the vendor measured alone. The clause defines what data the vendor delivers before that conversation and what the buyer can dispute. Without it, the renewal is discussed over a one-sided measurement.

Is usage-based billing always cheaper than a SaaS contract?

No. The model charges consumption, and consumption varies. Measuring in the same dimension as the contract and holding a reporting clause give the buyer verification, not a discount. The price falls when consumption falls or the rate is renegotiated, and neither of those comes from the billing model. Without verification, the buyer only transfers the variation into the budget.

How should the budget be approved under this model?

By dimension, with a cap and an alert, instead of a fixed line per vendor. The approved amount becomes a limit with a warning trigger, and the buyer needs to know who answers when the trigger fires. Approving a closed number for a variable expense is the mistake the invoice charges months later.

What is usage-based billing?

Usage-based billing is the model in which the buyer pays for what it consumes, measured in a dimension declared in the contract, instead of a fixed license per term. The vendor writes the lines and reports them to the marketplace, and the invoice arrives on the agreed cycle. The definition shifts the risk: the amount stops being predictable from the contract and starts depending on consumption inside the month.

References and Further Reading

Primary sources

• Build AWS Marketplace SaaS metering with the metering agent skill, AWS Marketplace, October 13, 2026, accessed October 21, 2026.
• SaaS pricing models, AWS Marketplace Buyer Guide, accessed October 21, 2026.

Complementary reading

• SaaS pricing models in a cloud marketplace
• Hidden risk at renewal
• SaaS procurement policy
• Reducing SaaS cost without renegotiating the contract
• Buying software in a cloud marketplace

What to do with this at the next renewal

A consumption contract is not cheaper by definition. Measuring your own consumption in the same dimension the vendor uses buys verification, not a discount: what makes it cheaper is consuming less or negotiating the rate, and that conversation is decided before signature, not on the invoice. Three actions, in the order that produces results.

First, ask for the report of one closed cycle, which is the test of the clause. Second, fix format, periodicity, the person responsible for sending it and the dispute window. Third, build the internal measurement in the contract's dimension: without it, the dispute becomes an opinion against a spreadsheet. In that order, not another.

For whoever is about to change channels, buying software in a marketplace starts with the same test, and buying software in a cloud marketplace describes the path. For whoever renews in the current channel without a reporting clause, the cost arrives in the following cycle: the month's variation enters the software budget as an inherited cost, and the dispute becomes a credit negotiated after the provision has closed.