For decades, the math in the Accounts Receivable department was straightforward. You issued an invoice for $1,000. The customer sent a check for $1,000. You matched the two, cleared the open item, and moved on.

‍

That reality has shifted. As B2B payments move increasingly toward credit cards and digital wallets, the numbers rarely match perfectly anymore. A $1,000 invoice might result in a $970 deposit (if you absorb the fee) or a $1,030 charge to the customer (if you surcharge). In both cases, the bank statement, the payment processor data, and the ERP open item are speaking different languages.

‍

Credit Managers are now tasked with more than just collecting funds. They are managing complex fee structures that sit on top of the principal debt. When these fees are not handled correctly in the workflow, they create significant reconciliation gaps, distort cash positions, and force teams to spend hours manually adjusting journal entries to make the books balance.

‍

The Disconnect Between Gateways and Ledgers

The core difficulty in modern cash application isn't usually the invoice itself. It is the extra line items that appear during the payment process. When a customer pays via a portal or a third-party processor, the transaction often splits. The invoice principal goes one way, and the fee goes another. Sometimes they are netted out before they hit your bank account. Other times, they are grossed up and charged separately to the customer.

‍

For the credit team, this creates a data problem. You know the customer paid, but the amount hitting the bank doesn't match the open item in your ERP. This forces the cash application team to investigate the variance. Is it a short payment? Is it a fee? Is it a deduction?

‍

Credit teams attempting to configure their payment flow to ensure that fees are calculated and routed correctly describe the challenge: they have to build in the surcharging piece to go out to the processor to get the fee.

‍

This highlights a critical mechanical gap. The "surcharging piece" is not just a policy decision. It is a data object that must exist between the ERP (where the invoice lives) and the processor (where the money moves). If that piece is missing or misconfigured, the fee is either not collected, or it is collected but never recorded back to the customer's account, leaving the ledger in disarray.

‍

Why ERPs Struggle with Surcharges

Why is adding a simple fee so disruptive to cash application workflows? The answer lies in the architectural differences between how ERPs record debt and how payment processors move money.

‍

Static vs. Dynamic Totals

Most ERPs operate on static open items. Invoice #12345 is for $500. That number is hard-coded into the sub-ledger. However, a credit card surcharge is dynamic and calculated at the moment of payment based on the card type or the total basket size. When the payment event occurs, the total transaction value changes to $515 (assuming a 3% fee). The ERP is effectively blind to this $15 variance until the data comes back from the bank.

‍

The "Netted" Settlement Problem

Many processors deposit funds on a "net" basis. If a customer pays $1,000, the processor might strip out their $30 fee and deposit $970 into your account. Your ERP expects $1,000. Your bank shows $970. The cash application team sees a $30 short payment. Without a specific workflow to identify that $30 as a "merchant fee" expense rather than a customer underpayment, the system flags it as an exception requiring manual review.

‍

Data Silos Between Gateway and ERP

Often, the logic for the surcharge lives in the payment gateway, not the ERP. The gateway calculates the fee and charges the card. However, if that gateway does not write back a specific "fee line item" to the ERP immediately, the AR team is left with a payment that exceeds the invoice amount (if surcharged) or falls short (if absorbed), with no supporting documentation attached to the transaction record.

‍

Timing Mismatches

Surcharges are often batched differently from principal payments. Some processors withdraw fees in a lump sum at the end of the month, while others deduct them per transaction. If your cash application process assumes a one-to-one match between daily sales and daily deposits, a month-end fee withdrawal will disrupt reconciliation for the entire period.

‍

Framework: Building a Fee-Aware Cash App Workflow

Credit Managers need to move away from treating fees as "exceptions" and start treating them as a standard part of the data payload. This requires a workflow that accounts for the fee before the funds reach the bank.

‍

Pillar 1: The Policy Logic (Who Pays?)

Before configuring the system, you must define the logic. This determines the direction of the variance.

‍

• Surcharge Model: The customer pays the fee. The payment amount exceeds the invoice amount. You need a workflow to recognize the excess as "Fee Revenue" or "Liability" rather than an overpayment.
• Absorption Model: You pay the fee. The deposit amount is less than the invoice amount. You need a workflow to automatically write off the difference to a "Bank Fees" GL account up to a specified percentage (e.g., 3%).

‍

Pillar 2: The Data Handshake

This step involves the integration between your order-to-cash system and the gateway.

‍

• Pre-Authorization: The system must calculate the fee before the customer clicks pay. This total (Principal + Fee) must be passed to the processor explicitly.
• The Return Trip: Crucially, the processor must return a file that separates these two values. You cannot accept a single lump sum data point. The return file (often a BAI2 or MT940 format) needs to parse the transaction into "Principal" and "Surcharge."

‍

Pillar 3: The GL Mapping

Once the data enters your environment, it needs a home. A common mistake is dumping surcharges into a miscellaneous revenue bucket. This creates audit risks.

‍

• Surcharge Liability Account: If you are collecting fees to pass them on to the processor, this is not revenue. It is a liability. The cash app workflow should book the principal to the AR Trade account (clearing the invoice) and the fee to a clearing account.
• Expense Offset: When the processor takes their cut, it should come out of that clearing account, not your general operating expenses.

‍

Why This Matters

Fixing the "surcharging piece" has direct financial and operational implications for the broader business.

‍

Margin Protection

In low-margin distribution or manufacturing sectors, a 3% credit card fee can wipe out a significant portion of the net profit on an order. By successfully implementing a surcharging workflow, you effectively protect that margin. If your workflow fails and you cannot reliably collect or reconcile these fees, the business may revert to absorbing them simply to avoid the operational headache.

‍

Audit and Compliance

Surcharging is heavily regulated. Different states and card networks (Visa, Mastercard) have strict rules about how much you can charge and how it must be disclosed. If your cash application process is guessing which amounts are fees and which are payments, you risk non-compliance. A structured workflow ensures that every surcharge is documented, traceable, and tied to a specific transaction.

‍

Customer Trust

Nothing erodes trust faster than billing errors. If a customer agrees to pay a surcharge, they expect their balance to be cleared in full. If your team misapplies the payment (e.g., posting the fee as principal and leaving a small balance on the invoice, or vice versa), it results in confusing statements and unnecessary disputes. A clean workflow ensures the customer's account is updated accurately the moment payment is made.

‍

Scalability

Manual journal entries do not scale. If your team handles 50 invoices a month, manually adjusting for fees is annoying but manageable. If you handle 5,000 invoices, it is impossible. As your volume of digital payments grows, the automated handling of these variances becomes essential to keeping the department running.

‍

Practical Implementation: The Workflow

When you are required to "build in the surcharging piece," you are essentially configuring the API payload. The workflow should look like this:

‍

• Trigger: Customer selects invoices totaling $10,000.
• Calculation: The system identifies the payment method (e.g., Commercial Card).
• The "Piece": The system appends a line item for $300 (3%).
• Submission: The system sends a request for $10,300 to the processor.
• Receipt: Processor confirms the capture of $10,300.
• Application: The ERP receives the signal. $10,000 is applied to the invoices. $300 is applied to the "Surcharge Collected" GL code. The open item is closed.

‍

Without the final application step being automated, the ERP sees $10,300 and doesn't know what to do with the extra $300, resulting in an unapplied cash bucket that grows indefinitely.

‍

Conclusion: An Actionable Playbook

Managing fees and surcharges is a technical challenge, but it is necessary for modernizing B2B payments. The goal is to ensure that the cost of acceptance doesn't become a cost of administration.

‍

Checklist to Evaluate Your Current Readiness

• Review Your Gateway Configuration: Does your payment processor allow you to separate the fee from the principal in their reporting? Are you receiving "Gross" or "Net" deposits?
• Map Your GL Accounts: Do you have a dedicated GL account for "Surcharges Collected"? Do you have a dedicated GL account for "Merchant Fees Paid"? Are these accounts reconciled monthly?
• Define Variance Thresholds: If you are not surcharging, what is the automatic write-off limit for bank fees? (e.g., small wire fees). Is this threshold set in your ERP to auto-clear small discrepancies?
• Audit the Customer Experience: Does the customer see the fee as a separate line item on their receipt? Does their statement reflect that the invoice is fully paid, or does the fee confuse the remaining balance?

‍

By addressing the "surcharging piece" upfront, you prevent the downstream chaos of mismatched ledgers and confusing audits. It allows your credit team to focus on credit risk, rather than chasing 3% variances across thousands of transactions.

‍

Struggling to reconcile credit card surcharges and processing fees? Bectran's cash application system automatically separates principal payments from surcharge fees, maps them to the correct GL accounts, and handles both netted and grossed-up settlements, eliminating manual journal entries and keeping your ledgers balanced. See how fee-aware cash app works.