How to Track Usage in Real Time: A B2B SaaS Founder's Guide to Metering and Overages

Before you can charge customers based on usage, you have to measure it — accurately, in real time, and in a way that your billing system can consume. Most founders think about metering as a technical problem. It's not. It's a revenue problem. The decisions you make about how to instrument usage, what events to capture, and how your metering layer talks to your billing system will determine how much revenue you collect, how quickly you can change your pricing, and how defensible your invoices are when customers dispute them. For B2B SaaS companies that process transactions for their customers and charge pass-through fees for adjacent services, this problem is more complex than it looks.

Metering vs. billing: two systems, two different jobs

These are two separate systems that founders routinely conflate — and rebuilding the one you got wrong costs months.

Metering is the process of capturing and recording usage events — every API call, every transaction processed, every token consumed, every SMS sent, every support case opened. The metering system's job is to capture raw events accurately and in real time. It is the source of truth for what actually happened.

Billing is the process of taking those events and translating them into an invoice. The billing system applies pricing logic — rate tiers, overage rules, minimum commits, customer-specific contracts — to the usage data the metering layer produces.

The distinction matters because one system should almost never change once it's right (metering), while the other changes frequently as you iterate on pricing (billing). As Kshitij Grover, CTO of Orb, explains: metered billing sends the billing system a final tally, while usage-based billing sends raw events. The difference is whether your pricing logic lives in your product code or in your billing platform — and that difference has massive downstream consequences for your ability to dispute invoices, change pricing, and serve enterprise contracts.

Step 1: Instrument your events before you price anything

The most important rule in metering: track everything you might ever want to price on, even if you're not pricing on it today.

James Wood, former head of pricing at Segment and advisor to over 500 SaaS companies, puts it directly: build metering like a product. Track every metric you could potentially price on. That flexibility lets you run scenario models, adapt quickly, and avoid a months-long rebuild if you change your pricing structure.

For B2B SaaS companies that process payments and enable transactions, the events worth instrumenting from day one typically include:

• Transaction count and volume — by customer, by endpoint, by product line
• API calls — by type, by customer, by environment (exclude dev/sandbox)
• Pass-through service events — SMS messages sent (e.g. via Twilio), letters printed and mailed (e.g. via Lob), voice AI minutes, support cases opened and resolved
• Active connected accounts or tenants
• Chargebacks and refunds — flagged separately, not netted against transaction count

That last point matters. Chargebacks and refunds are not just financial adjustments — they are events that can distort your reported usage. If you charge a pass-through fee for a service attached to a transaction, and that transaction reverses, the service cost may already have been incurred. A letter sent via Lob can't be unsent. A Twilio message can't be recalled. Your metering layer needs to track these separately so you can reconcile what was billed, what was reversed, and what you're still owed.

You don't need to price on all of these immediately. You need the data so that when you decide to change your pricing metric, you can model the revenue impact on your existing customer base before you make the change, not after.

Step 2: Choose your metering architecture

There are three approaches, each with different tradeoffs:

Build it yourself
Your engineering team instruments events directly into your product and sends aggregates to your billing system. This is what most early-stage companies do because it's the fastest path to a first invoice.

The problem: as Metronome co-founder Scott Woody learned at Dropbox, a homegrown system that handles aggregates — not events — eventually becomes the bottleneck for every pricing change. At Dropbox, a pricing update took six months to go live — not because of sales training or web copy, but because the billing system had to be re-engineered to support the new structure. "The billing system was the long pole for product launches," Woody said.

Use a purpose-built metering + billing platform
Platforms like Metronome (acquired by Stripe) and Orb ingest raw events and handle pricing logic in their systems — not yours. You send events; the platform applies your pricing rules, handles customer-specific contracts, and produces the invoice. Changing a price becomes a configuration change, not an engineering project.

Hybrid: internal metering, external billing
Some companies instrument events internally and pipe them to a billing platform via API. This preserves control over data capture while offloading pricing logic and invoice generation. Requires clear ownership of where billing logic lives.

Step 3: Understand where overage risk actually lives

For B2B SaaS companies that process payments, there is no overage on payment processing itself. You process a transaction, you charge a fee, the volume scales with your customer's GMV. That's a clean, linear relationship.

The overage risk lives in the adjacent services that vertical SaaS increasingly bundle: customer support, SMS notifications, paper statement delivery, voice AI for dispute resolution. This is where the metering problem gets harder — and more expensive to get wrong.

The SMS and pass-through services problem
Twilio charges per message. Lob charges per letter sent. These are usage-based costs that pass through to your customer as a line item or embedded fee. If your customer disputes a charge or a transaction reverses, the message or letter has already been sent and the cost already incurred. Your metering layer needs to capture these events at the moment they fire — not when the invoice is generated — so you have an accurate record of what was delivered regardless of what happens downstream in the payment flow.

The outcome-based support problem
Many vertical SaaS now bundle customer support — dispute resolution, onboarding calls, account management — and increasingly price it on outcomes: per case resolved, per dispute closed. This sounds clean. In practice it creates significant overage exposure.

The problem is outcome definition. If a "resolved case" isn't precisely defined in the contract, a single customer issue can trigger a cascade of billable events: multiple Twilio messages, several voice AI interactions, three email threads, a callback. Each of these has a per-unit cost from your underlying provider. If you've committed to resolving cases for a flat fee without capping the underlying activity, you can end up with negative margin on your busiest customers.

Intercom's Fin.ai pricing model — $0.99 per resolution — works because "resolution" is explicitly defined: the customer confirms the answer is satisfactory, or exits without escalating to a human. That definition is the margin protection. Without an equally precise definition in your contract, outcome-based pricing for support services becomes an open-ended cost commitment.

Step 4: Design overage logic before you launch adjacent services

If your product includes SMS, voice AI, or any per-unit communication or support service, you need overage logic before you go live — not after.

Three decisions to make:

1. Define the outcome, not just the service
Before pricing on "cases resolved," define exactly what counts as a resolution, what doesn't, and what happens if resolution requires more than N interactions. The definition in your contract is your margin protection.

2. Hard cap or soft limit on underlying API calls?
For services like Twilio or voice AI, a hard cap on per-case API consumption protects you from runaway costs on edge cases. A soft limit with alerts lets you catch anomalies before they become billing problems. Either way, you need a limit — uncapped API consumption tied to a flat outcome price is a margin risk.

3. When does overage get billed?
Monthly in arrears is most common, but creates a 30–60 day gap between consumption and collection. The cleaner approach — especially for pass-through services — is to bill as close to real-time as your billing platform supports, so anomalies surface quickly rather than compounding for a month.

Step 5: Give customers visibility before they get a bill

The single most common source of overage disputes is surprise. Customers who can see their consumption in real time manage it. Customers who can't will dispute the invoice.

Minimum viable customer-facing usage dashboard:

• Current period consumption vs. limit
• Projected end-of-period usage at current rate
• Alert at 70%, 90%, and 100% of limit
• Breakdown by service type — transactions, SMS, support cases — not just a total

That last point is specific to vertical SaaS: a single invoice line for "platform usage" doesn't give your customer enough information to understand or verify their charges. Itemizing by service type is the difference between an invoice that closes quickly and one that opens a dispute.

Common mistakes founders make

• Sending aggregates instead of events — you lose the ability to dispute-proof invoices and change pricing without re-engineering
• Not excluding dev/sandbox from billing — customers see charges for internal testing and lose trust immediately
• Netting chargebacks against transaction count — distorts real usage volume and creates rev rec errors when services are attached
• Launching outcome-based support pricing without defining the outcome — turns a flat fee into an open-ended cost commitment
• No ownership of the metering layer — metering touches product, engineering, finance, and CS; without a named owner it degrades over time

What good metering does for your business

Revenue: you can model pricing changes against your existing customer base before you make them — fewer surprises, faster iteration.

Cash flow: real-time usage data lets you forecast the current month's revenue before the period closes — critical when billing in arrears on pass-through services.

Retention: consumption patterns by cohort tell you which customers are growing, which are shrinking, and which are at risk — often months before a renewal or churn event.

Margin protection: itemized event tracking — especially for pass-through services like SMS and voice AI — lets you catch anomalies before they become negative-margin months.

Sources: Kshitij Grover, Orb — "Metered Billing vs. Usage-Based Billing: What Are the Key Differences"; Steve Love & James Wood, Operators Guild — "Making Usage-Based Revenue Work" (March 2026); Scott Woody, Metronome CEO, Grace Gong interview (January 2026); Scott Woody, The Room Podcast (April 2026); Operators Guild Demo Day — "Revenue Automation & Billing" (2025)