Guide

From Customer Payment to Bank Reconciliation: Best Practice for Oracle Fusion

Published 19 October 2026.

In short

In Oracle Fusion, payment to bank reconciliation works best as two separate steps. When the processor confirms a payment, record a receipt and apply it so the invoice closes. When the processor’s payout lands in your bank, reconcile that net deposit and its fees. Your receipt class decides how Oracle treats the second step.

Key takeaways

Push the receipt to Oracle and apply it the moment the invoice is paid, not when the money reaches your bank. The payout is a separate event with its own reconciliation.
For card payments paid out in net batches, the simplest sound setup is the Directly clearance method (the receipt counts as cleared as soon as it is created), posting to a PSP clearing account. Bank transfers suit By Matching (the receipt waits until you match it to a line on your bank statement). You can run both side by side.
Every receipt has two states: applied, meaning the invoice is paid, and cleared, meaning Oracle treats the cash as confirmed. A card payment should be applied as soon as the customer pays; when it clears depends on your clearance method.

A customer pays an invoice by card. A few seconds later Stripe says the payment succeeded. Two days later a single deposit lands in your bank, smaller than the payment, mixed in with other customers’ money. Getting payment to bank reconciliation right in Oracle Fusion Receivables is mostly about not confusing those two moments.

For a CFO the stakes are concrete. An invoice left open after the customer has paid inflates DSO, distorts the cash flow forecast and gets chased again, which annoys a customer who did nothing wrong. A clearing balance that never ties hides cash you cannot explain at month end.

This guide explains the options finance teams actually have, in plain terms, with small worked examples. It covers payments taken by an outside processor such as Stripe and recorded in Oracle as manual receipts. Cards processed through Oracle’s own payments module follow a different flow, with automatic receipts and standard remittance. Nothing here is a mandatory configuration. Your controller and your chart of accounts decide, and the examples show what each choice looks like in the books.

Key terms, in plain words

New to some of these words? Here is what each one means in this guide.

Applying a receipt: Linking the receipt to the invoice it pays. This is what lowers the invoice balance and marks it paid.
Unapplied cash: Money recorded in Oracle but not yet linked to any invoice. The customer has paid, but the invoice still looks open.
Processing fee expense account: The general ledger account where the processor's fees are booked as a cost. Fees go here, never against the invoice or the customer's receipt.
PSP clearing account: A holding account in your general ledger for money the processor has collected but not yet sent to your bank. Think of it as money in transit. Its balance should always equal what the processor still owes you. Using one is common best practice.
Remittance account: Oracle's holding account for a receipt that is recorded but not yet cleared. When the receipt clears, the money moves from here to the Cash account.
Receipt method and receipt class: Oracle settings that decide how a type of payment is recorded. You might have one receipt method for card payments and another for bank transfers. Each method belongs to a receipt class, and the class holds the clearance method.
Clearance method: The Oracle setting that decides when Oracle treats a receipt's cash as confirmed. There are three. Directly: confirmed as soon as the receipt is created. By Automatic Clearing: confirmed after a set number of days. By Matching: confirmed only when you match the receipt to a line on your bank statement.
Cleared: Oracle's word for a receipt whose cash it treats as confirmed. When that happens depends on the clearance method.
Cash Management: The part of Oracle Fusion where you load your bank statements and match each statement line to what Oracle expected.

Two events, not one

Every customer payment through a processor goes through two separate events.

Event 1: the payment succeeds (seconds)

Customer pays $100
By card on the payment page
Stripe confirms
Status: succeeded
Receipt in Oracle
Pushed and applied to the invoice the moment it is paid
Best practice
Invoice paid
Collections stops chasing

Event 2: the payout lands (days later)

Stripe batches
Many payments, fees taken off
Stripe payout to bank
One net deposit, here $97
Finance reconciles
Bank $97 plus fee $3 equals $100

Event	What changes	What does not happen yet
1. The payment succeeds	The customer no longer owes you. A receipt is created in Oracle and applied, and the invoice is paid or partly paid.	The money has not reached your bank. It sits with the processor.
2. The payout lands	The processor sends one deposit, usually covering many payments, with its fees already taken off. Finance reconciles that deposit.	No second receipt, and no second application to the invoice.

Best practice: push the receipt to Oracle and apply it to the invoice the moment the invoice is paid. In real time where your integration allows, the same day at the latest, and never when the payout arrives. Every hour a paid invoice stays open in Oracle, your aging report is wrong, your DSO reads higher than it is, and collections may chase a customer who has already paid.

The trap sits inside event 1. A card payment is usually confirmed in seconds, but a bank debit such as ACH sits in a processing state, which Stripe says can take up to a few days. Wait for the processor to report success before you create the receipt. A payment that has only been started has not settled anything.

The three Oracle clearance methods, in plain words

In Oracle Fusion, every receipt method belongs to a receipt class, and the class sets the clearance method. Oracle offers three clearance methods. They decide when Oracle treats a receipt as cleared cash. They do not decide when the invoice gets paid; applying the receipt does that.

Clearance method	What it means	Good fit
Directly	The receipt counts as cleared the moment it is created and posts straight to the Cash account set on its receipt method's bank account. No further step.	Card payments, when the receipt posts to a PSP clearing account rather than your real bank account.
By Automatic Clearing	Oracle's Clear Receipts Automatically program clears receipts a set number of days after their maturity date.	Weaker evidence than the other two: the date is an estimate, not proof of a deposit.
By Matching	The receipt waits in the Remittance account until you match it to a bank statement line in Cash Management.	Payments that reach the bank one at a time, such as bank transfers.

One setup detail for whoever configures Oracle: payments taken outside Oracle are recorded as manual receipts. Oracle’s own Cash Management worked example for matching uses a receipt class with manual creation, No Remittance (which Oracle describes as being for manual receipts only) and By Matching. Confirm the exact combination in your own environment.

By Matching, explained simply

Here is By Matching step by step. In one sentence: the invoice is paid straight away, but Oracle will not treat the cash as confirmed until it finds the money on your bank statement.

How a receipt clears By Matching

1. Receipt applied
The invoice is paid. The cash is recorded but not yet confirmed.
2. Statement loaded
Your bank statement is loaded into Oracle Cash Management, usually daily.
3. Match found
Oracle pairs the receipt with a statement line, by its rules or by hand.
4. Receipt cleared
The cash now counts as confirmed in the bank.

Step 3 is the whole method. Oracle’s reconciliation matching rules compare things like the amount, the date and a reference, and they can match one receipt to one statement line or group several together. Whatever Oracle cannot match waits for someone to match it by hand.

Where By Matching works well

When one payment arrives as one bank line. A customer sends a $100 bank transfer, your statement shows $100 with their reference, and Oracle matches the two without help. This gives you the strongest proof that the cash really arrived.

Where it struggles

When a processor pays out in batches. Three Stripe payments of $50, $100 and $150 create three receipts totalling $300, but the bank shows one line of $291, because Stripe kept $9 in fees. No receipt equals $291, and even all three together do not, so the match fails until someone accounts for the fees. That is why card payments typically clear Directly into a PSP clearing account instead, and why combining By Matching with a clearing account needs Stripe’s payout report to match against.

One habit matters if you use it: load bank statements every day. Receipts only clear when there is a statement to match them to, so a late statement leaves a pile of uncleared receipts that looks like a problem but is only a delay.

Every receipt has two states: applied and cleared

This is the idea that makes the rest of the guide click. In Oracle, the receipt, not the invoice, carries two separate states, and each answers a different question.

	Application state	Clearing status
The question	Is the invoice paid?	Does Oracle treat the cash as confirmed?
Typical values	Unapplied, then Applied	Remitted, then Cleared (with Directly: Cleared from the start)
When it changes	When the receipt is applied to the invoice, at event 1	Depends on the clearance method: at once (Directly), after set clearing days (By Automatic Clearing), or when a bank line is matched (By Matching)
Who watches it	Collections, and anyone reading DSO	Treasury and the controller

The invoice itself only has a balance: open while money is owed, closed once applied receipts cover it. So a receipt can be Applied but not yet Cleared. A card payment should be applied as soon as the customer pays; when it counts as cleared depends on your clearance method: at once with Directly, or only after a bank match with By Matching. Oracle’s screens and its receipts API label the two fields differently, so go by the values rather than the field name.

The PSP clearing account is a separate choice

A PSP clearing account is an ordinary general ledger asset account for money your payment processor owes you. It answers a different question from the clearance method: which account does the receipt hit before the money reaches the bank?

Why it helps: your processor pays out in batches, net of fees. If every card receipt posted straight to your bank cash account, the bank account in Oracle would show money your real bank has not received yet. A clearing account holds it in between, and its balance should always equal what the processor still owes you. When it does not, you have found a problem worth looking at.

Best practice: if you take payments through a processor, use a PSP clearing account. It is the common, widely used way to account for processor money, in Oracle and in any other ledger. A few habits make it work well:

Keep one clearing account per processor, and one per currency if you settle in more than one.
Reconcile it to every payout, using the processor’s payout report.
Check that each payout clears exactly the payments, fees and refunds it contains, so the balance always equals what the processor still owes you. Any other difference is a fee, refund, dispute or timing gap that still needs explaining.

And a separate account for processing fees

The clearing account has a partner: a processing fee expense account. When a payout lands, the bank receives less than the clearing account holds, and the difference is the fees. They are booked to this expense account, using the processor’s payout report as evidence.

Record the customer’s receipt at the full amount they paid. A $100 payment is a $100 receipt, even though only $97 reaches the bank.
Book fees as a cost in their own account. Do not net them off revenue or off the receipt, or the invoice will look underpaid and your sales figures will be wrong.
Watch the account monthly. Fees divided by the value you collected through the processor is your effective processing rate, and a jump is worth investigating: it can come from a pricing change or a shift in card mix.

Your options, side by side

These are the three setups worth knowing. They are not exclusive, because each receipt method can sit in its own receipt class.

Option 1: Directly, posting to a PSP clearing account

The receipt is created and applied when the payment succeeds, and it lands in the PSP clearing account: with Directly, Oracle posts the receipt to the Cash account set on its receipt method's bank account, so you point that account at PSP clearing rather than the real bank. When the payout arrives, you move the money from the clearing account to the bank and book the fee. Simple, and the invoice closes at once. This is the typical setup for card payments through a processor.

Option 2: By Matching, straight to the bank

The receipt is applied to the invoice straight away, but stays uncleared until a bank statement line matches it in Cash Management. Strong evidence, because every receipt ties to a real bank line. It works well when each payment arrives on its own, and badly when one net payout covers fifty card payments, because no single bank line equals any single receipt. Forcing it there turns every month end into a manual puzzle, and that costs headcount. This is the typical setup for bank transfers.

Option 3: By Matching with a PSP clearing account

The strictest version. Receipts are first matched to the processor’s own record of each payment, which clears them into the PSP clearing account. The clearing account is then reconciled to the net bank payout. It works, but it needs a second source to match against, usually the processor’s itemised payout reconciliation report, loaded in a form Oracle can match. Choose it when your controls require each receipt to show as matched inside Oracle, and plan the setup with whoever owns your Cash Management configuration. Weigh the extra control against the cost per payment of running two reconciliations instead of one.

Oracle has a fourth possibility, By Automatic Clearing, which clears receipts a set number of days after their maturity date. The date is an estimate rather than proof of a deposit, so it gives weaker evidence than the other two, and this guide does not cover it further.

Option 1 or Option 3?

Both options have proof for every payment, the processor’s payout report, and both close the invoice the moment the customer pays. The difference is where the proof is recorded.

	Option 1: Directly + PSP clearing	Option 3: By Matching + PSP clearing
Receipt counts as cleared	The moment it is created	Only after it is matched in Cash Management
Where the proof is checked	Per payout: the payout report ties to the PSP clearing balance	Per receipt, inside Oracle: each receipt matched to its line in the payout report
What you need	The processor's payout report	The payout report loaded into Cash Management
Effort each month	Low	Higher
Choose it when	Proving cash at payout level is enough (the typical default)	Controls require each receipt to show as matched inside Oracle

Where the money sits in each option

Option 1: Directly + PSP clearing Typical for cards

Accounts receivablepayment succeeds

PSP clearingpayout lands

Bank

Option 2: By Matching

Accounts receivablepayment succeeds

Remittance accountbank line matched

Bank

Option 3: By Matching + PSP clearing

Accounts receivablepayment succeeds

Remittance accountmatched to payout report

PSP clearingpayout lands

Bank

Combining them

If you take more than one kind of payment, mix them. A typical mix: card payments through the processor on Option 1, and bank transfers customers send directly to your account on Option 2. Each has its own receipt method, so each follows its own rules.

Your situation	Usually the best fit
Card payments paid out in net batches	Option 1
Bank transfers that arrive one by one	Option 2
Controls require each card receipt to show as matched inside Oracle	Option 3
Both cards and bank transfers	Option 1 for cards, Option 2 for transfers

Worked examples

Small numbers, so the logic is easy to follow, with Stripe as the processor. The fees are round numbers for easy reading, not Stripe’s actual pricing. Each table shows the debit and credit for every step. Your exact Oracle account names depend on your own setup.

A. One Stripe card payment: $100 paid, $3 fee, $97 paid out (Option 1)

When	Debit	Credit
Payment succeeds, receipt applied	PSP clearing $100	Accounts receivable $100
Stripe payout lands	Bank $97, Processing fees $3	PSP clearing $100

End result: the invoice is paid, the bank holds $97, the fee expense is $3 and the clearing account is back to zero.

Customer still owes: $0
Bank received: $97
PSP clearing left: $0
Fee expense: $3

B. Three Stripe payments, one payout

Three invoices of $50, $100 and $150 are each paid by card and each closed by its own receipt. Two days later Stripe sends one payout of $291, after $9 of fees.

When	Debit	Credit
Three payments succeed	PSP clearing $300	Accounts receivable $300
One Stripe payout lands	Bank $291, Processing fees $9	PSP clearing $300

Stripe’s payout reconciliation report (available with automatic payouts) lists the three payments and the fees inside that $291, which is what you reconcile against. Nothing about the payout touches the invoices.

C. A bank transfer: $100, no fee (Option 2)

When	Debit	Credit
Receipt created and applied	Remittance account $100	Accounts receivable $100
Bank line matched in Cash Management	Bank $100	Remittance account $100

D. One Stripe payment, matched per receipt (Option 3)

The same $100 card payment as example A, but each receipt is matched inside Oracle before it counts as cash. Three steps instead of two.

When	Debit	Credit
Payment succeeds, receipt applied	Remittance account $100	Accounts receivable $100
Receipt matched to its line in Stripe's payout report	PSP clearing $100	Remittance account $100
Stripe payout lands	Bank $97, Processing fees $3	PSP clearing $100

The invoice is paid at step 1, exactly as in example A. The receipt stays Remitted until step 2, when Cash Management matches it and it becomes Cleared. Step 3 is the same payout reconciliation as option 1.

E. A partial Stripe payment: $40 against a $100 invoice

The receipt is for $40 and is applied for $40. The invoice stays open for $60, and collections carries on for the rest. The $40 reaches the bank in a Stripe payout like any other payment.

When things go wrong

What happens	Good practice
Bank debit still processing	No receipt yet. Create it when the processor reports success.
Payment fails or is returned after the receipt was applied	Reverse the receipt through your approved process, so the invoice reopens and collections resumes. Guard against creating a duplicate when the customer pays again.
Refund	Use your refund, credit memo or reversal process. A refund does not automatically mean the original invoice should reopen.
Card dispute or chargeback	Follow your company policy: reverse the receipt or record a chargeback. Avoid reopening the invoice automatically.
Payout does not match	Compare the payout report line by line: fees, refunds, disputes, reserves and currency conversion are the usual causes.

Best practice for payment to bank reconciliation in Oracle Fusion

These hold in any ERP and are widely accepted finance practice:

Push the receipt to Oracle and apply it as soon as the processor confirms the payment: in real time where your integration allows, the same day at the latest.
Wait for the processor to report success on bank debits such as ACH before you record anything.
Never create a second receipt for the same payment when the payout arrives.
Record the receipt at the full amount the customer paid, and book processing fees to their own expense account when you reconcile the payout.
Hold processor money in a PSP clearing account and reconcile it to every payout using the processor’s payout report.
Before go-live, test one payment, several payments in one payout, a partial payment, a delayed bank debit, a refund, a chargeback and a reversal.

And the typical Oracle Fusion setup:

Give each payment channel its own receipt method, so cards and bank transfers can follow different clearance rules.
Card payments: Directly, posting to the PSP clearing account (Option 1). Bank transfers: By Matching (Option 2). Option 3 only when your controls require each receipt to show as matched inside Oracle.

Where Finero fits

Finero collects the payment and handles event 1, following exactly this best practice. It pushes a standard receipt to Oracle the moment the processor confirms the payment, not in a nightly batch. The receipt carries the invoice number, so Oracle knows which invoice it pays. It uses the receipt method you choose, for example a separate one for each processor, so the clearance method and accounts follow your own Oracle setup rather than ours. Oracle applies the receipt to the invoice, or on release 26C Finero asks Oracle to apply it to the exact installment that was paid and then checks what Oracle actually did. It never sets an invoice to paid directly; in Oracle a payment closes an invoice through an applied receipt, and it never creates a second receipt at payout time.

The payout side, event 2, stays in your normal Cash Management process. See how the Oracle Fusion integration works, or read about cash application more broadly.

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.

See autonomous AR invoice collection in action

Book a 30-minute demo with a Finero expert. See how Finero chases, collects, and reconciles invoices end-to-end.

30 minutes · No commitment

Oracle Fusion payment reconciliation FAQ

Should the Oracle receipt be created when the customer pays or when the payout arrives?

The moment the invoice is paid, which is when the payment processor confirms the payment succeeded. Best practice is to push the receipt to Oracle and apply it to the invoice as soon as that happens: in real time where your integration allows, and the same day at the latest. That is when the customer's debt is settled, so that is when the invoice should close. The payout days later is a different event: money moving from the processor to your bank, net of fees. Creating the receipt at payout time leaves paid invoices open for days and invites customers to be chased for money they have already paid.

Which receipt clearance method should I use for card payments in Oracle Fusion?

For card payments that arrive as pooled, net payouts, the simplest sound setup is Directly with the receipt posting to a PSP clearing account rather than the real bank account. The receipt closes the invoice straight away, and the clearing account is reconciled to each payout. By Matching suits payments that reach the bank one at a time, such as bank transfers, because each receipt has a bank line to match.

Is a PSP clearing account one of Oracle's clearance methods?

No. Oracle has three clearance methods: Directly, By Automatic Clearing and By Matching. A PSP clearing account is a general ledger account for money the processor owes you. It is a separate choice and can sit behind any of the three methods, depending on which account your receipt method posts to.

Can I use By Matching together with a PSP clearing account?

Yes, but it is a two-stage design and it does not happen by ticking both. The bank statement shows one net payout, not the individual gross receipts, so you need a second source to match the receipts against, usually the processor's itemised payout report. It adds a receipt-level control and costs the most effort. Option 1 is backed by the same payout report but checks it once per payout; here each receipt shows as matched inside Oracle. Choose it when your controls require that receipt-level match.

Can I use different options for different payment types?

Yes. The clearance method lives on the receipt class, and each receipt method belongs to a class, so card payments through your processor can use one receipt method and bank transfers another. A typical setup is card payments on Directly with a PSP clearing account, and bank transfers on By Matching.

Where do processor fees go in Oracle?

Not on the customer's invoice. The customer paid the full amount, so the receipt is for the full amount. The fee appears when you reconcile the payout: the bank receives the net amount and the difference is booked to a processing fee expense account, using the processor's payout report as evidence.