Most teams that implement surcharging don’t realize the real problem isn’t whether to charge the fee. It’s whether your platform can actually handle it.
When surcharging goes wrong
Here’s what usually happens. A finance leader runs the numbers on payment processing costs, gets uncomfortable with the 1.5–2% bleed across all invoices, and decides: we’re going to implement surcharging. It’s a smart move. For a mid-market company processing $50 million in annual invoices, that’s potentially $750K back in margin.
Then they flip the switch.
Initially, it works. A few invoices go out with a surcharge applied. Customers pay them. The finance team sees the margin recovery and thinks they’ve solved it. But then scaling happens. Recurring billing invoices need surcharges, but the team doesn’t have rules for those. Usage-based overages come through—do those get surcharged? Some customers need one-off exceptions. Before long, the team is managing surcharges in spreadsheets, handling exceptions manually, and the overhead is eating the margin they just recaptured.
By month three, nobody’s sure if surcharging is actually working. Nobody’s tracking whether customer behavior shifted toward cheaper payment methods. And the support team is fielding confused customers who saw the surcharge on their invoice for the first time and want to know why.
This is the difference between surcharging as a feature and surcharging as an operational model. And it’s the difference between platforms that bolt surcharging on and platforms that build it in from the ground up.
What actually needs to happen
If surcharging is going to work at scale, a few things need to be true.
Your payment method surcharges need to match your actual costs.
A credit card costs you 2.9% + $0.30 to process. ACH costs you $0.25. A wire transfer costs $15 flat. An international bank transfer varies by currency and corridor. If your platform applies a blanket 2% surcharge across everything, you’re either overcharging customers for cheap methods (they subsidize the expensive ones) or undercharging for expensive ones (you miss the margin). Worse, you’re not creating the incentive structure that actually changes behavior—which is the whole point.
Real surcharging infrastructure means you set surcharges by payment method. You can mix fee types: percentage for cards, flat fee for ACH, tiered pricing for international transfers. You can test scenarios before deployment. And critically, you can adjust rates without rebuilding invoices manually.
Surcharges need to apply automatically, or they won’t scale.
Most teams test surcharging on one-off invoices first. That works fine. Then they try applying it to recurring billing, variable invoices, usage-based overages. Suddenly they’re dealing with invoice-by-invoice overrides and reconciliation nightmares. The operational overhead eats the margin recovery.
This is where automation matters. Surcharge rules need to persist across invoice types. If you set a rule—credit cards get surcharged 2.9%—it applies to every invoice, every time, without manual intervention. When payment comes in and a customer selects their method, the surcharge calculates automatically at the point of payment. Not after the fact, not in back-office reconciliation. In the moment, transparently.
You need to see what’s actually happening with surcharges.
This is where most implementations break. A company applies surcharges, collects them, but then can’t answer basic questions. How much surcharge revenue did we collect last month? Did customer behavior actually shift? Are we seeing customers migrate to cheaper payment methods, or is everyone still using credit cards despite the surcharge?
If your platform hides surcharge data in the revenue line or buries it in transaction logs, you can’t optimize it. You need surcharge totals separated clearly. You need reporting by payment method mix and how it’s changed. You need to see which customers are consistently choosing expensive methods, so you can reach out and guide them toward cheaper options. You need to understand whether surcharging is working or if it’s just adding complexity.
Customers need to understand it before they pay.
A common implementation mistake: Platform applies surcharges silently. Customer sees the final amount at payment, gets surprised, and either abandons the transaction or contacts support confused. Your team spends hours explaining the fee.
The better way: Make the surcharge visible on the invoice itself. Show it again at payment checkout before the customer commits to a method. Customize the label for clarity (“Credit Card Processing Fee” not “Payment Method Surcharge”). Give customers the choice. They can see the why, understand the tradeoff, and decide whether the convenience of their preferred method is worth the cost.
This builds trust instead of friction.
Everything needs to integrate cleanly with how you actually invoice and collect.
Surcharging can’t be a bolt-on feature. It needs to work with complex billing: invoices with multiple line items, usage-based overages, discounts, partial payments. If a customer pays part of an invoice via ACH (no surcharge) and part via credit card (surcharge), does the system calculate correctly? If an invoice is amended, does the surcharge recalculate? If payment posting fails, does the surcharge roll back?
If surcharging doesn’t integrate smoothly into your billing flow, you create accounting headaches and manual workarounds that quickly erode the economic benefit.
Common problems that point to platform misfit
You can usually spot a surcharging implementation that’s about to break by looking at a few things:
Surcharges are the same across all payment methods. That’s a red flag. It means the platform isn’t designed for method-specificity, so you’re either overpaying on some transactions or missing margin on others.
Every surcharge change requires manual updates. If your team has to manually update pending invoices when surcharge rates change, the platform didn’t build automation in. That overhead adds cost and introduces errors.
Surcharge data is hard to find in reporting. If surcharge revenue is mixed into your general revenue line or buried in transaction logs, your platform isn’t designed for visibility. You can’t optimize what you can’t see.
Customers see the surcharge for the first time at payment. That suggests no transparency layer was built in. Which means friction, support burden, and potentially customer churn.
Your accounting system doesn’t separate surcharge revenue clearly. If your GL doesn’t show surcharge revenue separately from invoice revenue, reconciliation becomes a nightmare. That’s a platform integration problem.
What mature surcharging actually looks like
When surcharging is built in properly, it works differently.
You set rules once: credit cards get surcharged 2.9%, ACH doesn’t, international wires get a flat $15 fee. The platform applies those rules automatically to every invoice, every time. When a customer selects their payment method, they see the surcharge calculated in real time, on the invoice and at checkout. They understand the why and can choose. They pay. The surcharge is reconciled automatically. Your accounting system shows surcharge revenue separately. Your finance team can see what’s actually happening—how much surcharge revenue came in, whether customer behavior shifted, which accounts are driving the margin recovery.
And because it’s all automated, it scales. A spike in invoices doesn’t require hiring more staff. A new currency or payment method is added as a configuration change, not a system rebuild. Recurring billing, usage-based pricing, complex contracts—they all work with surcharging built in.
That’s the difference between a feature and infrastructure.
The real question
When you’re evaluating an AR platform for surcharging, don’t ask “does it support surcharging?” Ask instead: “Is this platform built around surcharging, or was it added on later?”
If it was added on, you’ll feel it immediately. Rule configuration will be clunky. Automation won’t be thorough. Reporting will be hard. Customer visibility will be an afterthought.
If it was built in from the ground up, surcharging just works. Rules are simple to configure. Automation handles the heavy lifting. Visibility and reporting are built in. Customer communication is transparent and natural.
The difference in operational burden—and in actual margin recovery—is significant.
Ready to implement surcharging that actually works?
Invoiced by Flywire is built around the reality of variable payment costs. Method-specific surcharging, automated application and reconciliation, transparent customer communication, and clean integration with your entire I2C workflow. Surcharging becomes a lever for margin recovery, not a source of operational headache.
Get a demo today to see how surcharging infrastructure works in Invoiced.
