The AP monetization gap that most programs don't expect
An AP automation platform launches a virtual card program. The projections showed $2M in annual interchange revenue at current payment volume. Twelve months later the program is generating $380K. The volume is there. The card program is working. The economics aren't.
This scenario — call it the AP monetization gap — is common enough that it has a predictable set of causes. The gap is almost never about payment volume. It's almost always about VCard acceptance rate, supplier enrollment, BaaS economics, and operational design.
Root cause 1: Supplier enablement was treated as a launch activity, not an ongoing operation
The single largest driver of AP monetization underperformance is low virtual card acceptance rates — programs running at 8–15% acceptance when 40%+ is achievable. The difference is supplier enablement.
Supplier enablement is not a software feature or a one-time integration. It is an ongoing operational program: identifying VCard-eligible suppliers, contacting their AR departments, supporting their VCard integration or AR workflow changes, and maintaining enrollment as supplier AR staff turns over and payment workflows change.
Programs that treat supplier enablement as a launch campaign — send some emails, upload the supplier portal, call it done — plateau at 10–15%. Programs that staff and fund supplier enablement as an ongoing operation reach 40%+ over 18–24 months. The economics difference between these two outcomes at $100M annual payment volume is approximately $4.4M in annual interchange revenue.
Root cause 2: The program architecture wasn't designed for monetization
Many AP automation platforms designed their payment programs for operational efficiency — reliable payment delivery, good reconciliation, clean supplier experience — without designing explicitly for monetization. The payment waterfall puts ACH before VCard (lowest cost, not highest revenue). The BIN is a consumer card BIN (low interchange, not a commercial purchasing card BIN). The revenue share agreement with the BaaS provider was never negotiated for platform economics.
Fixing architecture after launch is expensive and slow. Redesigning the payment waterfall requires touching every supplier payment flow. Changing BINs requires re-issuing card capabilities and potentially re-integrating with the card network. Renegotiating BaaS economics requires contract leverage the platform may not have.
Root cause 3: Economics leaked to the BaaS layer
Programs running on BaaS-provided card infrastructure typically share interchange with the BaaS provider. A platform projecting $2M in interchange revenue at 175 bps may discover their actual net is 70–90 bps after the BaaS share — generating $800K–$1.03M rather than $2M. The BaaS provider captured $970K–$1.2M that the platform's model didn't account for.
The fix for this specific cause is migrating to a direct bank relationship — which recovers the full interchange economics but requires 6–18 months and significant operational investment.
Root cause 4: Monetized ACH wasn't implemented
Most AP platforms monetize VCard but leave ACH volume generating zero incremental revenue. An AP platform running 60% ACH at $100M annual volume, with a $1.50 monetized ACH fee on 30% of that volume, generates $900K annually from ACH alone. Programs that launched without a monetized ACH product — enhanced remittance, aggregated payment, or premium ACH service — leave this on the table indefinitely.
If your AP monetization is underperforming projections, the AP payments calculator can help you identify which levers apply. Or talk with us directly — we can usually diagnose the primary cause in 30 minutes.