Yes, Dynamics 365 can apply compliant payment surcharges. Both Business Central and Finance & Operations support surcharging through a connector or extension, since neither product processes card payments natively. A successful setup means the surcharge calculates correctly every time, posts to the right G/L account, discloses clearly to the customer, and reconciles cleanly against your bank deposit.

Two implementation patterns dominate: adding a surcharge as a distinct invoice line, or posting the fee as a separate G/L entry when payment is received. Before you touch configuration, run through this checklist:

• Confirm surcharging is legal in your state, province, or country
• Select a connector or extension that automates the calculation
• Map surcharge revenue and PSP fee expense to separate G/L accounts
• Test every payment path in a sandbox before going live

Key Takeaways

Dynamics 365 surcharging succeeds when the surcharge calculates automatically, posts to a dedicated G/L account, discloses clearly to the customer, and reconciles against gross transaction value, PSP fees, and net deposit every month.

Point	Details
Confirm legality first	Check state, country, and card-network rules before configuring any surcharge percentage or fixed fee.
Map G/L accounts explicitly	Route net payment, surcharge revenue, and PSP fee expense to three separate accounts, never one clearing account.
Test every payment path	Validate standard sale, partial payment, payment-link redemption, and refund reversal in a sandbox before launch.
Recheck configs after upgrades	Verify charge codes, G/L mappings, and compliance caps survived every Dynamics 365 platform update.
Use a processor-agnostic connector	Sensepass links Dynamics 365 to 100+ payment methods and 50+ processors, keeping surcharge posting logic consistent even when you switch PSPs.

Table of Contents

• How Dynamics 365 Surcharging Works Behind the Scenes
• Setting Up Surcharge Fields in Business Central and F&O
• Posting and Reconciling Surcharge Income Against PSP Fees
• Compliance Checks Before You Turn Surcharging On
• Making Surcharging Work Operationally
• Why a Connector Approach Simplifies Surcharging in Dynamics 365
• Keeping Surcharge Configurations Current Through Upgrades
• What Actually Matters When You Implement This
• Get Surcharging Live in Dynamics 365 Without the Reconciliation Guesswork
• Frequently Asked Questions
• Sources

How Dynamics 365 Surcharging Works Behind the Scenes

Dynamics 365 surcharging comes down to two questions: where does the fee show up, and what triggers it? Most implementations use one of two signage approaches. The first adds a surcharge line directly on the invoice, visible to the customer before they pay. The second posts a surcharge entry only when the payment method is confirmed as card, which keeps the original invoice clean but requires tighter automation on the back end.

Calculation logic follows a predictable structure:

1. Percentage-based — a flat percentage of the transaction total, the most common model for card surcharging
2. Fixed amount — a set fee in local currency regardless of transaction size
3. Combination — a percentage with a minimum or maximum cap, common where card-network rules limit surcharge size
4. Capped surcharge — Business Central setups can define a maximum limit so a large invoice doesn’t generate an outsized fee

The mechanics change depending on the payment path. A partial payment needs the surcharge recalculated against the remaining balance, not the original total. A payment link generated after the invoice posts has to pull the current surcharge rule, not a stale one baked in at invoice creation. Prepayments complicate things further, since the surcharge should typically apply to the actual card-paid portion, not the full order value.

Setting Up Surcharge Fields in Business Central and F&O

Configuring surcharging correctly starts with structure, not switches. Get the setup right once and it holds through renewals, rate changes, and processor swaps.

• Create charge codes and charge groups. Business Central users typically build a dedicated charge code (something like “CARD SURCHARGE”) and group it so it can be applied consistently across customers and sales documents.
• Decide header level versus line level. A header-level charge applies once per invoice; a line-level charge lets you exclude specific items (a common requirement when surcharging is restricted on debit transactions but allowed on credit).
• Add the payment-method surcharge fields. Vendor documentation for Business Central lists the core fields you need: surcharge percentage, fixed local-currency amount, a maximum limit, and the G/L account the surcharge should post to.
• Configure auto charges. Auto-charge rules apply the fee automatically based on the payment method selected, rather than relying on a user to add it manually.
• Validate against edge cases. Test what happens when a customer switches payment method mid-transaction, or when a payment link is issued after the invoice already posted.

Pro Tip: Run your sandbox tests with a payment method switch mid-invoice before you go live. That single scenario surfaces most G/L mapping errors before they hit production.

Posting and Reconciling Surcharge Income Against PSP Fees

Reconciliation is where most Dynamics 365 surcharging implementations either hold up or quietly fall apart. The mechanics matter here more than in almost any other part of the setup.

The net payment amount posts to the Customer Ledger Entry, while the surcharge itself posts as a separate line, typically to a surcharge revenue account or a contra-expense account depending on your chart of accounts. Your processor’s own fee, the amount the PSP actually charges you for running the transaction, needs its own expense account entirely separate from the surcharge revenue line.

Keep these four figures visible at all times:

• Gross transaction amount
• Surcharge collected from the customer
• PSP processing fee charged to you
• Net bank deposit

The most common failure mode is incomplete G/L mapping, which leaves surcharge income sitting in a clearing account instead of a dedicated ledger line. Finance teams should track surcharge income and PSP expense as two separate metrics, not a net figure, because netting them hides whether surcharging is actually recovering costs or just moving numbers around. Build test scenarios for refunds (does the surcharge reverse too?), partial payments, and chargebacks before you trust the reconciliation report.

Compliance Checks Before You Turn Surcharging On

Surcharging legality is not uniform. Some US states restrict or ban it outright, several countries cap the allowable percentage, and card networks like Visa and Mastercard layer their own disclosure requirements on top of local law. Australia’s consumer regulator, for example, publishes explicit guidance on what counts as a permissible surcharge versus an excessive one.

Before enabling surcharging in Dynamics 365, confirm:

• The surcharge is legal in every jurisdiction where you sell
• Checkout, invoice, and payment-link disclosures clearly state the surcharge before the customer pays
• Your rate doesn’t exceed any regional cap on surcharge percentage
• The configuration change ticket logs the policy, the legal reference you checked, and the review date

Documented compliance history isn’t paperwork. It’s the record that answers a card-network audit or a customer dispute months after the setup went live.

Making Surcharging Work Operationally

A well-configured surcharge that customers don’t understand generates support tickets, not goodwill. Treat the rollout as a communication project as much as a technical one.

1. Publish a short surcharge policy. State the percentage or fee, why it exists, and which payment methods it applies to. Put it at checkout, on the invoice, and on payment links.
2. Train your front-line teams. Sales, customer service, and finance staff all need to know exactly how the surcharge appears on an invoice and how a refund affects it, since a surcharge that isn’t reversed on a refunded order is a fast way to lose customer trust.
3. Schedule a monthly reconciliation report. Compare surcharge income collected against actual PSP fees paid. If the gap is consistently negative, your rate isn’t covering your real processing cost, and it’s time to adjust.

Pro Tip: If your surcharge rate and your actual PSP fee drift more than a percentage point apart for two consecutive months, that’s your signal to revisit the rate, not just the reconciliation process.

Retailers balancing surcharge revenue against conversion risk often find it useful to review broader payment optimization tactics alongside surcharging, since a fee that’s technically legal can still push a hesitant customer toward abandoning checkout.

Why a Connector Approach Simplifies Surcharging in Dynamics 365

Dynamics 365 doesn’t process card transactions on its own. Every credible implementation guide points to the same conclusion: you need a connector or gateway layer to tokenize card data and keep raw card numbers out of the ERP entirely. That connector layer is also where surcharge automation genuinely pays off.

A connector-based setup typically behaves the same way across processors: the net payment lands in the Customer Ledger, the surcharge posts to whatever G/L account you’ve configured, and the PSP fee lands in its own expense account. The consistency is the point. You’re not rebuilding posting logic every time you touch a payment method.

Sensepass works as a payment connector, the integration layer linking a business’s ERP, POS, and eCommerce systems to more than 100 payment methods and 50-plus card processors through a single integration. Because Sensepass is processor-agnostic and merchants retain ownership of their own payment tokens, switching or adding a processor doesn’t require re-integrating your Dynamics 365 environment from scratch. Surcharging runs as one of the products on top of that connector layer, alongside the payment gateway, tap-and-pay, and pay-by-link.

A connector that owns the tokenization layer and stays processor-agnostic means a rate renegotiation or a processor switch is a configuration change, not a re-implementation project.

Keeping Surcharge Configurations Current Through Upgrades

Dynamics 365 upgrades, whether a Business Central version update or an F&O platform update, can silently affect surcharging configurations. Extensions and connectors that worked fine pre-upgrade sometimes need field remapping afterward, particularly if Microsoft changes payment-method table structures or G/L posting APIs between releases.

Build an upgrade checklist specifically for surcharging before you approve any sandbox-to-production migration:

• Re-test every payment path. Standard card sale, partial payment, payment-link redemption, and refund with surcharge reversal all need a fresh pass after any platform update.
• Confirm charge codes and charge groups survived the migration. Custom fields and extension-added tables are the most common casualties in an upgrade.
• Verify G/L account mappings didn’t reset to default. A surprisingly common failure mode is an upgrade quietly reverting a custom G/L mapping to a system default, which sends surcharge revenue to the wrong account without triggering an obvious error.
• Recheck compliance settings. If a card network or a jurisdiction changed its surcharge cap since your last review, an upgrade cycle is a natural checkpoint to confirm your rate is still within bounds.
• Document the change. Log the upgrade date, what was tested, and who signed off, the same way you logged the original compliance review.

Set a recurring calendar reminder tied to your Dynamics 365 release cadence rather than relying on someone to remember. Surcharge configurations that go untested through two or three upgrade cycles are the ones most likely to be quietly broken when finance finally notices the reconciliation numbers don’t add up.

What Actually Matters When You Implement This

Most guidance on Dynamics 365 surcharging treats it as a checkbox: turn on a percentage, add a line item, done. That framing undersells the real work. The technical configuration, the charge codes, the G/L fields, the auto-charge rules, is genuinely the easy part. Where implementations fail is reconciliation discipline and compliance documentation, the two areas that get the least attention in most setup walkthroughs.

The conventional advice also underweights how much processor flexibility matters over time. Teams that hard-code surcharge logic against one processor’s API tend to face a rebuild the moment they want to renegotiate rates or add a second processor for redundancy. That’s not a hypothetical risk. Processor contracts change, rates get renegotiated, and businesses expand into regions where their original processor doesn’t have coverage.

If you’re prioritizing one thing first, make it G/L mapping and the refund test case. A surcharge that calculates correctly but doesn’t reverse cleanly on a refund will generate more accounting headaches than a surcharge that’s simply not enabled yet. Get reconciliation right before you scale the rollout.

Get Surcharging Live in Dynamics 365 Without the Reconciliation Guesswork

Sensepass connects Dynamics 365, whether you run Business Central, Finance & Operations, or Commerce, to more than 100 payment methods and 50-plus processors through one integration, so the setup checklist covered above doesn’t have to be rebuilt every time you add a payment method or switch a PSP.

Because Sensepass is processor-agnostic and merchants keep ownership of their tokens, surcharging, along with the payment gateway, tap-and-pay, and pay-by-link products that run on the same connector, keeps working the same way even if you renegotiate rates or bring on a second processor. Net payments post to the customer ledger, surcharge revenue posts to the account you configure, and PSP fees post separately, so the reconciliation report actually matches what hit your bank account. If your business runs on NetSuite instead, the same connector logic applies there too.

Review the NetSuite and Dynamics 365 surcharging setup to see how the G/L mapping and disclosure requirements translate into your specific ERP, and get a walkthrough of what a sandbox test looks like before you flip surcharging on for real customers.

Frequently Asked Questions

Does Dynamics 365 calculate surcharges automatically?
Not on its own. Business Central and F&O need a connector or extension to automate the calculation, since neither product processes card transactions natively.

Can I surcharge only certain payment methods in Business Central?
Yes. Payment-method surcharge fields let you set a percentage, fixed amount, or maximum limit per method, so you can surcharge credit cards while leaving debit or ACH untouched.

What happens to the surcharge when a customer gets a refund?
The surcharge should reverse alongside the refund if your G/L mapping is configured correctly. This is one of the most commonly missed test cases in a sandbox rollout.

Is surcharging legal everywhere?
No. Rules vary by country, and within the United States, by state. Some regions cap the allowable percentage; others restrict surcharging on debit transactions specifically. Confirm your jurisdiction’s rules and your card network’s disclosure requirements before enabling it.

How does a payment connector like Sensepass fit into a Dynamics 365 surcharging setup?
Sensepass connects Dynamics 365 to 100-plus payment methods and 50-plus processors through a single integration, handling tokenization and posting net payments, surcharge revenue, and PSP fees to the accounts you configure, without requiring a rebuild if you switch processors later.

Sources

• How Surcharge Fees Are Posted to Microsoft Dynamics 365 Business Central
• Adding surcharge fees – Pay-It documentation
• Credit card handling in Business Central – Solving Dynamics 365

Recommended

• NetSuite Surcharging Solutions: Recover Card Processing Fees, Compliantly – Omnichannel payments at the Point Of Sale | Sensepass
• Migrate Payment Processors in Dynamics 365 Without Re-Integration – Omnichannel payments at the Point Of Sale | Sensepass
• How to Accept ACH Payments in NetSuite: 2026 Guide – Omnichannel payments at the Point Of Sale | Sensepass
• Dynamic Payment Method Strategy for Retail in 2026 – Omnichannel payments at the Point Of Sale | Sensepass