Every B2B payment program builds integrations. SAP, Oracle, NetSuite, QuickBooks, Sage — the ERP connector is the unsexy infrastructure that makes the payment flow work for enterprise customers. It maps the data, handles the exceptions, surfaces the payment status inside the workflow the AP team actually uses.
Almost no payment programs charge for it.
The integration is treated as implementation work — the cost of getting the customer live. It gets bundled into onboarding, priced at cost, or given away to close the deal. The reasoning is usually "it differentiates us" or "it reduces churn." Both are true. But they don't make it free to build or free to maintain. And more importantly, they underestimate what the integration is actually worth to the customer.
What an ERP connector actually does
When an AP team processes payments through a connected ERP, they don't think about payment rails or BaaS architecture. They think about whether the invoice matches the PO, whether the payment status is visible in the system, and whether exceptions get routed correctly without manual handling.
The integration is the layer that makes all of that work. It extracts payment data from the ERP, formats it for the payment network, handles the routing logic, captures the return data, and posts settlement back to the general ledger in the right format. For a mid-market AP team processing 2,000 invoices per month, a good integration removes 40–60% of manual touchpoints. That's measurable labor cost reduction — often several FTE equivalent.
Why programs give it away
Integration is given away for three reasons, and none of them are well-reasoned when examined.
First, the build team doesn't think of itself as a product team. Engineers built the connector to solve a technical problem. Nobody talked to the AP buyer about what the workflow improvement was worth. The value was designed in but never priced in.
Second, the sales motion anchored on transaction pricing. If the revenue model is per-transaction fees, every conversation is about volume and rate. The integration becomes a closing tool, not a revenue line. Once it's in the sales motion as a freebie, it's hard to reprice without a positioning change.
Third, competitive pressure. If competitors give integration away, there's fear that charging for it creates friction. The problem is that competitors who give it away have either modeled the revenue differently (it's in the transaction price) or they haven't noticed they have a margin problem.
The revenue model for integration
There are two monetization models for integration that work in practice.
Implementation fee plus platform tier. A one-time implementation fee covers the customization and go-live work. The ongoing platform subscription tier includes integration maintenance, updates, and support. The implementation fee is typically $5,000–$25,000 depending on ERP complexity. The platform tier differential is typically $500–$2,000 per month above the base tier. Both are defensible on ROI grounds when the AP team has quantified the manual work being eliminated.
Integration as platform tier differentiator. Enterprise-grade ERP connectors live in the highest pricing tier. Mid-market customers get standard integration. Enterprise customers — with SAP, Oracle, or custom ERP environments — pay enterprise tier pricing. The integration capability drives the tier differentiation. The pricing reflects the customer's scale and complexity, which correlates with the value delivered.
The connectors that carry the most leverage
Not all ERP connectors are equal from a monetization perspective. The connectors with the most pricing leverage are the ones that unlock the most automation in the customer's workflow — specifically, the ones that handle three things: outbound payment initiation directly from the AP module, inbound settlement confirmation that posts automatically to the ledger, and exception handling that routes to the right workflow without leaving the ERP environment.
SAP and Oracle connectors with all three capabilities are the highest-value integrations in B2B payments. QuickBooks and NetSuite connectors serve a different segment — SMB and lower mid-market — where the absolute price point is lower but the value-to-cost ratio is still strong. The pricing architecture needs to reflect the customer segment, not just the technical complexity.
What this means for program design
Integration monetization is a design decision, not a pricing retrofit. The decision needs to be made when the product is being designed: is the integration a closing tool or a revenue line? Both are valid answers — but they lead to different product architectures, different sales motions, and different economic models.
Programs that want to monetize integration need to build for it from the start: product packaging that separates integration from the base offering, implementation methodology that captures the ROI conversation during onboarding, and pricing tiers that reflect integration value. Programs that decide to add integration pricing post-launch usually find it requires a full packaging redesign — because the base offering has been sold including integration for long enough that customers won't accept a reprice.