In short
There are two places to add credit card surcharges in Oracle Fusion: on the invoice before it is sent, or at checkout when the customer picks a card. On the invoice is simplest. At checkout is fairer, because only card payers pay it, and the extra is typically billed in Oracle as a debit memo.
Key takeaways
- If you know in advance the customer will pay by credit card, put the surcharge on the Oracle invoice as its own line. One invoice, one receipt, nothing special to book.
- If the surcharge depends on how the customer pays, add it at checkout. The typical way to bill it in Oracle is a debit memo; a miscellaneous receipt or a journal entry also work, with more trade-offs.
- Check the rules first. Card networks, US states and the EU all limit surcharging, and a refund must return the surcharge too.
Card payments cost you money, and more B2B sellers now pass part of that cost to customers who choose to pay by credit card. Adding the surcharge is the easy part. Recording it properly is where finance teams get stuck, because credit card surcharges in Oracle Fusion can be booked in four different ways, and each one changes what Receivables, the general ledger and your bank reconciliation look like.
For a CFO the question behind it is simple. Card fees are real spend, and a surcharge recovers part of it without raising prices for customers who pay another way. That only helps cash flow if the surcharge is recorded cleanly and nobody has to unpick it at month end.
This guide walks through all four with the same small example, so you can compare them side by side. It assumes you already reconcile processor payouts the way our payment to bank reconciliation guide describes, with a PSP clearing account and a processing fee expense account.
Key terms, in plain words
- Surcharge
- An extra amount a customer pays for choosing a credit card, to cover what the card costs you to accept.
- Debit memo
- A small extra bill in Oracle for a charge that was not on the original invoice. Oracle uses the same document for things like freight and late charges.
- Miscellaneous receipt
- Oracle's record of money received that is not tied to any customer invoice, such as interest. It posts straight to an income account.
- Journal entry
- A manual or imported posting straight into the general ledger, outside Receivables.
- PSP clearing account
- A holding account for money the processor has collected but not yet paid out to your bank. Its balance should always equal what the processor still owes you.
- Surcharge income account
- The general ledger account where surcharge revenue is booked, kept apart from your sales revenue.
- Processing fee expense account
- The general ledger account where the processor's fees are booked as a cost. It stays separate from surcharge income.
Before anything else: are you allowed to surcharge?
Surcharging is restricted in many places, and the cost of getting it wrong falls on you, not your processor. The main rules for the payments B2B sellers see most:
| Where | The rule |
|---|---|
| US | Credit cards only, never debit or prepaid. Visa caps it at the lower of your processing cost or 3%, wants at least 30 days' notice to your acquirer, and requires it as a separate line. Some states add their own limits. |
| Canada | Credit cards only. Stripe supports up to 2.4%. |
| EU | PSD2 bans surcharging consumer cards. Corporate cards are outside the ban, but any surcharge is capped at what the payment actually costs you. |
| UK | The consumer ban goes further than the EU's. Check before surcharging anyone. |
Wherever it is allowed, three rules travel with it, according to Stripe’s surcharging guide: show the surcharge and the total before the customer pays, let them switch to another payment method, and return the surcharge on a refund. Visa’s merchant surcharging Q&A and Stripe’s note on the PSD2 surcharge ban have the detail. Whether the surcharge itself is taxable depends on where you sell, so ask your tax adviser too.
The example we use throughout
One invoice, one card payment, Stripe as the processor. The fee is a round number for easy reading, not Stripe’s actual pricing.
- Invoice
- $100
- Surcharge (3%)
- $3
- Customer pays
- $103
- Stripe fee
- $3
So Stripe collects $103, keeps a $3 fee and pays $100 into your bank. In every option below, the bank receives the same $100. What changes is how Oracle explains it.
Option 1: the surcharge is on the Oracle invoice
The simplest version. The invoice is raised in Oracle with two lines, $100 for the goods and $3 for the card surcharge, so the customer owes $103 before anyone pays anything.
- Invoice in Oracle$100 goods + $3 surcharge line = $103
- Customer pays $103By credit card through Stripe
- One receipt, $103Applied to the invoice the moment it is paid
- Stripe payout$100 to the bank, $3 fee
| When | Debit | Credit |
|---|---|---|
| Invoice raised | Accounts receivable $103 | Sales $100, Surcharge income $3 |
| Payment succeeds | PSP clearing $103 | Accounts receivable $103 |
| Stripe payout lands | Bank $100, Processing fees $3 | PSP clearing $103 |
Good: one invoice, one receipt, the surcharge is on a document the customer already has, and Receivables tells the whole story. The catch: you have to know the customer will pay by credit card before you invoice. If they pay by bank transfer instead, they now owe a surcharge they should not pay, and you need a credit memo to remove it. And changing an invoice the customer already holds is messy; a separate debit memo is cleaner.
Option 2: the surcharge is added at checkout
The invoice in Oracle stays at $100. When the customer opens the payment page and picks a credit card, the page adds $3 and shows a total of $103. If they pick a bank transfer instead, they pay $100 and no surcharge exists. That is fairer, and it is the main reason to surcharge at checkout.
Finero does not add surcharges, but some payment pages do, so it is worth knowing how the flow looks. Stripe collects $103 against a $100 invoice, and Oracle has to be told where the extra $3 belongs. There are three ways to do that.
2A. A debit memo for the surcharge (the typical choice)
Once the payment succeeds, a $3 debit memo is created in Oracle for the same customer. Then one $103 receipt is applied across both: $100 to the invoice and $3 to the debit memo. Both close, and the surcharge lives in Receivables like any other charge. Oracle already uses debit memos for charges that were not on the original invoice, such as freight and late charges, so this is a familiar document for your team.
- Invoice in Oracle$100
- Checkout adds 3%Customer pays $103 by credit card
- Debit memo, $3Created once the payment succeeds
- One receipt, $103$100 to the invoice, $3 to the debit memoTypical
| When | Debit | Credit |
|---|---|---|
| Invoice raised | Accounts receivable $100 | Sales $100 |
| Debit memo created | Accounts receivable $3 | Surcharge income $3 |
| Receipt applied to both | PSP clearing $103 | Accounts receivable $103 |
| Stripe payout lands | Bank $100, Processing fees $3 | PSP clearing $103 |
Good: the original invoice never changes, only card payers are charged, and every dollar the customer paid sits on a Receivables document. The catch: one more document per card payment, and the timing needs care. Create the debit memo only after the payment succeeds, so an abandoned checkout never leaves a stray $3 charge open. If creating it fails, the payment should wait and retry without ever creating two. For integrators, Oracle offers an active Debit Memo service (a SOAP web service), which needs a debit memo transaction type and a memo line set up in Oracle first.
2B. A miscellaneous receipt for the surcharge
No extra bill. The money is split into two receipts instead: a standard receipt for $100 applied to the invoice, and a miscellaneous receipt for $3 that posts to surcharge income.
| When | Debit | Credit |
|---|---|---|
| Standard receipt, applied | PSP clearing $100 | Accounts receivable $100 |
| Miscellaneous receipt | PSP clearing $3 | Surcharge income $3 |
| Stripe payout lands | Bank $100, Processing fees $3 | PSP clearing $103 |
Good: no extra document for the customer. The catch: one Stripe payment becomes two receipts in Oracle, which makes tracing and reconciliation harder. Miscellaneous receipts are meant for money that is not tied to a customer invoice, so ask your controller whether that fits your policy before you use them this way.
2C. A journal entry for the surcharge
Receivables only ever sees the $100 invoice payment. The $3 is posted to surcharge income by a separate journal entry in the general ledger.
| When | Debit | Credit |
|---|---|---|
| Receipt applied to the invoice | PSP clearing $100 | Accounts receivable $100 |
| Journal entry for the surcharge | PSP clearing $3 | Surcharge income $3 |
| Stripe payout lands | Bank $100, Processing fees $3 | PSP clearing $103 |
Good: Receivables stays clean, and it suits teams that already post fees and other income through a reliable journal process. The catch: Oracle will not post that $3 on its own. Something has to create the journal for every card payment and link it to the Stripe transaction. If it is missed, the PSP clearing account shows an unexplained $3 and the surcharge income is never recorded. Responsibility for that journal sits with your finance team, whoever builds the automation.
Which option for credit card surcharges in Oracle Fusion?
| Option | Best when | Main trade-off |
|---|---|---|
| 1. On the Oracle invoice | You know up front the customer pays by credit card | Wrong if they pay another way |
| 2A. Debit memo | The surcharge depends on how the customer pays | One more document per card payment |
| 2B. Miscellaneous receipt | Your controller approves income outside Receivables | One payment becomes two receipts |
| 2C. Journal entry | You already run a reliable journal process for fees | Needs a process that never misses one |
A typical setup: Option 1 when the surcharge is known in advance, and Option 2A, the debit memo, when it depends on how the customer pays. Option 2C is a sound alternative for teams with a strong journal process. Option 2B works, but splitting one payment into two receipts makes it the hardest to trace. Whichever you pick, make the business case on the numbers: surcharge income against processing fees, month by month.
Three more examples worth testing
Card or bank transfer: only card payers pay
The same $100 invoice shows two choices at checkout: credit card at $103 including the $3 surcharge, or bank transfer at $100. This is the main reason to add the surcharge at checkout rather than on the invoice.
A partial payment: $40 by card
The customer pays $40 of the $100 invoice by credit card, plus a 3% surcharge of $1.20, so Stripe collects $41.20. Oracle applies $40 to the invoice, which stays open for $60, and the $1.20 is booked by whichever option you chose. The surcharge never reduces or increases what is applied to the invoice.
A refund
A customer who paid $103 is refunded in full, so they get the whole $103 back, surcharge included. In Oracle, reverse both parts: the invoice receipt and the surcharge booking. Reversing only the invoice part leaves $3 of surcharge income that no longer exists. On a partial refund the surcharge is refunded in proportion.
Payout and reconciliation do not change
Whichever option you pick, Stripe still pays out the net amount, and each payout still clears exactly the payments, fees and refunds it contains, so the PSP clearing balance always equals what Stripe still owes you. Best practice is to keep the surcharge income and the processing fee expense in separate accounts rather than netting them. Comparing the two each month shows your effective processing rate (the cost per dollar collected), and whether the surcharge really covers it. For the full payout side, including By Matching, see the payment to bank reconciliation guide.
Where Finero fits
Finero does not add surcharges today. If your surcharge is on the Oracle invoice, as in Option 1, Finero collects the invoice total like any other invoice and pushes the receipt to Oracle the moment it is paid. Learn more about the Oracle Fusion integration.
Disclaimer. This guide is for general information only and is not accounting, tax or legal advice. Finero is not an accounting firm or financial consultancy. It is recommended to consult a certified accountant or your auditor on how these practices apply to your business.