September 2026 Summaries

Open-source billing systems can make coding agents more reliable not by improving their reasoning, but by giving them implementation details, executable tests, type-safe API contracts, and traceable billing calculations to verify their work. Closed billing APIs may lead agents to generate plausible but outdated or incorrect integrations, a particularly serious risk in billing where small metering errors can cause revenue discrepancies, customer disputes, and audit problems. Self-hostable source code allows agents to inspect edge-case behavior, run synthetic usage events and billing cycles locally, compare invoices with expected results, and trace charges through events, meters, rate cards, and grants. The approach still requires focused guidance, sandboxed environments, and human decisions about financial intent, but it recommends treating the invoice as an end-to-end test with explicit expected totals and line items.

Credit-based pricing for AI products should treat credits as a stable customer-facing unit of value rather than a direct reflection of fluctuating provider costs, allowing companies to preserve balances and plans as models and API pricing change. Effective pricing depends on calculating four variables: cost per credit, customer price per credit, fixed platform fee, and included credit allowance, which together determine revenue, costs, and margins at different usage levels. While fixed fees can produce high margins for low-use customers, such customers may be less likely to renew, and allowances exceeding their break-even consumption level can create losses before overage charges begin. Credit rates should account for cost differences across model tiers, input and output tokens, caching, context length, and priority levels, while teams should periodically reassess margins as provider pricing changes. The approach also recommends stable published credit definitions, usage ceilings and alerts, budget-owner notifications, per-customer margin reporting, and clear organizational ownership of pricing decisions.

Outcome-based pricing, currently used by about 5% of B2B software companies but expected by survey respondents to reach 31% within three years, appeals because customers pay only for successful results, yet it can expose vendors to substantial hidden costs from failed attempts. Illustrative calculations show that a seemingly profitable per-resolution price can approach zero margin when failures require more model inference, tool calls, and retries than successful tasks. To manage this risk, companies need defined task step, tool-call, and token limits; visible model-routing and customer-level cost attribution; clear contractual definitions of failure types and payment responsibility; and real-time, per-attempt controls rather than invoice-level reporting. Before adopting the model, vendors should also assess whether outcomes are consistent, attributable, measurable, and predictable, while addressing customer budgeting concerns through annual commitments, spending floors and ceilings, or alternative pricing options.

A 2026 survey of 230 B2B software and AI companies found that hybrid pricing, AI credits, and outcome-based models are expected to expand significantly, while flat-fee and per-seat pricing declines. Hybrid models depend on enforceable usage caps to prevent unprofitable consumption, while AI products’ median target gross margin of roughly 50%—far below traditional SaaS margins—makes per-customer cost attribution and controls especially important. Credits are increasingly common but require transparent balances, predictable consumption, customer-configurable limits, and stable value definitions to avoid confusing buyers or retroactive repricing. Outcome-based pricing can strengthen customer value propositions but shifts the cost of failed or inefficient attempts to vendors, increasing the need for per-request cost management. Across these models, the central requirement is that entitlements, balances, limits, and cost decisions operate in real time during service delivery rather than only through post-use invoicing systems.

Seat-based pricing is declining in B2B software as AI disrupts the link between the number of users, product usage, and customer value, while increasing infrastructure costs make traditional SaaS economics less viable. However, seats continue to serve a practical role as a predictable fixed fee for procurement, even as major vendors supplement them with consumption-based credits. Pure usage pricing better reflects delivered work but can create unpredictable revenue and customer bills, particularly for smaller customers or organizations facing sudden usage spikes. As a result, hybrid pricing is becoming the preferred approach despite being harder to explain, combining low-cost seats as access fees with charges based on measurable outcomes such as tickets resolved or documents processed. For this model to work, companies must set consumption limits across organizational, team, and individual levels so customers retain budget control while vendors can monetize AI-driven usage.

As software companies, particularly high-ACV B2B vendors, increasingly withhold public pricing to preserve negotiating flexibility, AI purchasing agents are becoming more likely to exclude opaque providers from consideration because they rely on retrievable, machine-readable information rather than sales interactions. The argument distinguishes public price pages from agent-ready pricing infrastructure, which should include a structured and versioned rate card, an endpoint showing each customer’s entitlements and remaining balance, and API-based methods for quotes, commitments, or credit purchases. Many companies struggle to provide this information because their actual pricing is fragmented across spreadsheets, CPQ systems, contracts, and sales judgment rather than maintained as canonical data. Treating pricing as queryable, versioned data can enable flexible repricing, grandfathering, internal support visibility, and agent-facing transactions without requiring publication of every negotiated discount. The recommended priorities are to create a centralized rate-card model, expose entitlement information, and produce unambiguous documentation defining billing units and conversions, positioning pricing transparency as an API interface rather than merely a marketing choice.

Usage-based billing systems accurately record, aggregate, and price past consumption but cannot prevent costs once an event has occurred, making downstream spending limits primarily notifications rather than true controls. The passage argues that metering and entitlement checks should operate in the request path, where a proxy or access layer can verify balances and reject calls before expensive model or API usage occurs, including across third-party services. Combining usage measurement and authorization in one system reduces discrepancies caused by separate balances and stale concurrent reads, although distributed balance data remains eventually consistent and may permit limited overspend during short update windows. It recommends deliberately choosing fail-open or fail-closed behavior based on request type and applying limits at organization, customer, team, or individual-key levels so a single runaway agent does not affect all users. Beyond protecting margins, visible and reliable customer-controlled limits may encourage consumption by reducing uncertainty about usage-based bills.

Although many B2B software firms now change pricing and packaging frequently using flexible no-code billing tools, the harder problem is evaluating whether a proposed change will benefit the business and customers before it is launched. The text advocates replaying a new rate card against historical, event-level usage data to calculate what each customer’s invoices, margins, and allowance consumption would have been under the proposed model, revealing affected accounts, unprofitable usage patterns, and distributional effects that aggregate spreadsheet forecasts can obscure. It recommends testing new pricing first with new customers, monitoring feature adoption across billing cycles, and migrating existing customers transparently through versioned plans, grandfathering, price locks, and advance communication. This approach depends on retaining detailed usage events, treating rate cards as versioned data rather than application code, and separating metering from pricing so historical usage can be repriced easily.

Agentic systems make cost attribution difficult because a single user task can involve multiple billable calls to model providers, MCP servers, partner APIs, and internal services, many of which are outside an organization’s control and cannot be instrumented with an SDK. The proposed solution is to meter traffic at a gateway or proxy through which all requests pass, allowing it to capture customer and team identity, destination, model or tool usage, token counts, outcomes, and latency without requiring cooperation from upstream services. Effective attribution also depends on propagating a run identifier across all downstream calls and resolving identity at the edge, linking otherwise separate events to a specific agent run and customer. MCP tool calls should be treated as billable usage because their costs can vary substantially, while proxy-based metering enables per-run budgets, step limits to prevent loops, tool-specific pricing, and the ability to reject requests before additional spending occurs.