Oracle Prepayment Testing

What Is a Prepayment in Oracle Payables?

A prepayment is a special invoice type in Oracle Payables used to record an advance to a supplier. You enter it as a Prepayment invoice, validate it, obtain approval where required, and pay it like any other invoice. Once paid and past its settlement date, its unapplied amount becomes an available balance that can be applied to one or more standard invoices from the same supplier — reducing the amount due on those invoices without a second cash disbursement.

Oracle distinguishes two kinds. A temporary prepayment is intended to be applied against future invoices and carries a running available balance. A permanent prepayment is never applied — it settles as an outright payment — so it must be blocked from the application flow entirely. Application can be partial or full, can be reversed through unapplication, and the whole prepayment can be cancelled before it is paid.

The teams that depend on prepayments behaving correctly are AP processors who create and apply them, supervisors who approve advances and authorise reversals, functional consultants who configure supplier and invoice options, and finance and audit teams who reconcile the prepaid-advances account. Upstream dependencies are the supplier, supplier site, and tax setup; downstream dependencies are payment, accounting through Subledger Accounting, and period close.

Scope note. This page owns the prepayment lifecycle — creation, payment, availability, application, unapplication, reversal, cancellation, and prepayment balances. The mechanics of paying the prepayment invoice through payment batches, Payment Process Requests, and bank files are covered on Oracle Payment Processing Testing; general disbursement behaviour lives on Oracle Payments Testing. Here we focus on the prepayment itself and how it is applied.

Why Testing Prepayments Matters

A prepayment is a balance that persists across periods and interacts with tax, currency, and multiple later invoices. A defect rarely fails loudly — it silently mis-states an advance or lets a supplier be paid twice. The risks specific to the prepayment lifecycle:

Risk	Example	Potential impact	Testing response
Double payment	Standard invoice paid in full without applying the prepayment	Supplier paid twice for one obligation	Assert prepayment applied before net payment
Balance not decremented	Application posts but available balance unchanged	Over-application; overstated advances	Assert balance after each partial application
Application before availability	Applied before payment or settlement date	Credit taken against unfunded advance	Negative test: block application when unavailable
Over-application	Applied amount exceeds remaining balance	Negative invoice; reconciliation break	Boundary test at and beyond balance
Permanent applied	Permanent prepayment offered for application	Advance mis-classified; wrong accounting	Assert permanent is never applicable
Cross-currency error	Application converts at the wrong rate	FX gain/loss mis-stated	Test application across currency and rate cases
Tax mis-handled	Tax on prepayment not recovered on application	Tax over/under-statement; compliance	Validate tax on creation and on application
Unapplication gap	Unapply restores invoice but not balance	Balance lost; audit trail break	Assert balance restored on unapplication
Closed-period posting	Application accounting date in a closed period	Failed accounting; close block	Test accounting date vs open/closed periods
Cross-BU / wrong supplier	Prepayment applied outside its BU or supplier	Mis-allocated advance; control gap	Negative test on BU and supplier restrictions
Silent behaviour change	Quarterly update alters application or accounting	Undetected control drift	Release-aware regression on prepayments

The Oracle Prepayment Process Flow

A prepayment is created as its own invoice type, validated and approved, and paid. Only after payment and settlement does its balance become available for application against standard invoices — and only then does the running balance begin to move.

Prepayment lifecycle sequence

Prepayment created → Validated → Approved → Paid → Becomes available → Applied to standard invoice → Remaining balance updated → Unapplied or fully consumed → Accounting & reconciliation

Trigger: a Prepayment-type invoice is entered manually, via REST, or through file-based import for eligible suppliers and sites.
Availability gate: a temporary prepayment can be applied only after it is paid and its settlement date has passed; a permanent prepayment never becomes applicable.
Application: the available balance is applied — partially or fully — to one or more standard invoices from the same supplier, reducing amount due and decrementing the balance.
Exception paths: unapplication reverses an application and restores the balance; the whole prepayment can be cancelled before payment; reversal creates offsetting accounting.
Expected output: an accurate remaining balance, correct net amount on each standard invoice, and balanced accounting on every event.
Downstream impact: application and reversal entries flow to Subledger Accounting and the General Ledger, and feed the prepaid-advances reconciliation.

Suggested visual: a swimlane diagram of the prepayment lifecycle with the availability gate and the unapplication/cancellation branches, for the web team to produce.

Temporary vs Permanent Prepayments

The prepayment type decides whether the advance ever enters the application flow. Testing both types — and confirming the boundary between them — is the first thing a prepayment suite must establish.

Dimension	Temporary prepayment	Permanent prepayment
Purpose	Advance to be recovered against future invoices	Outright payment never recovered (e.g. deposit)
Application	Applied, partially or fully, to standard invoices	Never applied — must be excluded from application
Available balance	Maintains a running balance until consumed	No available balance to track
Settlement date	Gates when the balance becomes applicable	Governs payment timing only
Reversal path	Unapplication restores balance; cancellation before payment	Cancellation before payment only
Key test focus	Application, balance accuracy, unapplication, tax recovery	Blocked from application; correct one-off accounting

Prepayment Lifecycle Stages

Each stage changes state, balance, or accounting — and each is a distinct test surface. The table maps the stage to what must be true when it completes.

Stage	What happens	Balance effect	Expected outcome to assert
Created	Prepayment-type invoice entered for eligible supplier/site	None yet	Type, supplier, amount, tax captured correctly
Validated	Validation runs; distributions and tax checked	None	Validated status, no unexpected holds
Approved	Approval workflow routes and completes	None	Approved by the correct role/rule
Paid	Prepayment disbursed to the supplier	Advance recorded	Paid status; prepaid-advances account debited
Available	Settlement date passes; balance opens for application	Full amount available	Available balance = paid amount (net of tax rules)
Applied	Balance applied to one or more standard invoices	Decrements by applied amount	Invoice amount due reduced; balance updated
Balance updated	Remaining balance recalculated after each event	Remaining = available − applied	Running balance accurate across events
Unapplied	A prior application is reversed	Balance restored	Invoice amount due and balance both reinstated
Consumed	Balance fully applied	Remaining = 0	Prepayment shows fully applied; no residual
Cancelled	Prepayment cancelled before payment	Reversed to zero	Cancellation allowed only pre-payment; accounting reversed
Accounted & reconciled	Events posted through SLA to GL	Reflected in prepaid account	Balanced entries; sub-ledger ties to GL

Prepayment Application-Rule Matrix

Application is only allowed when a set of conditions all hold. Each rule is a positive case (allowed) and a matching negative case (blocked) the suite must cover.

Rule	Allowed when	Blocked when	Automation
Type	Prepayment is temporary	Prepayment is permanent	High
Payment status	Prepayment is fully paid	Unpaid or partially paid	High
Settlement date	Settlement date has passed	Settlement date in the future	High
Supplier match	Same supplier as the standard invoice	Different supplier	High
Business unit	Within the same or permitted BU	Cross-BU where not permitted	Medium
Available balance	Applied amount ≤ remaining balance	Applied amount > remaining balance	High
Currency	Matching currency, or handled conversion	Mismatched currency with no rate	High
Period status	Application date in an open period	Date maps to a closed period	High
Role privilege	User holds apply/unapply privilege	User lacks the privilege	Medium

Oracle Prepayment Test Scenarios

A representative set of 34 Oracle Fusion prepayment scenarios — creation and eligibility, availability gates, partial and full application, balance accuracy, tax and currency, exception paths, integration, roles, and regression. Test IDs use the AP-PP prefix.

ID	Scenario	Preconditions	Expected result	Pri	Auto
AP-PP-001	Create temporary prepayment	Eligible supplier/site, Prepayment type	Created and validated; temporary flag set	H	Y
AP-PP-002	Create permanent prepayment	Prepayment type marked permanent	Created; never offered for application	H	Y
AP-PP-003	Supplier / site eligibility check	Site not enabled for prepayments	Creation blocked or flagged per setup	M	Y
AP-PP-004	Prepayment date recorded correctly	Prepayment entered with a set date	Date drives accounting and reporting	M	Y
AP-PP-005	Settlement date governs availability	Paid prepayment, settlement date future	Not yet available for application	H	Y
AP-PP-006	Available-for-application after settlement	Paid; settlement date passed	Full balance available for application	H	Y
AP-PP-007	Payment required before application	Prepayment validated but unpaid	Application blocked until paid	H	Y
AP-PP-008	Application attempt before availability	Unpaid or pre-settlement prepayment	Application denied (negative test)	H	Y
AP-PP-009	Partial application to one invoice	Available balance > invoice amount	Invoice reduced; balance decremented	H	Y
AP-PP-010	Full application consuming balance	Applied amount = remaining balance	Balance = 0; prepayment fully applied	H	Y
AP-PP-011	Application across multiple invoices	One prepayment, several invoices	Balance decrements correctly per invoice	H	Y
AP-PP-012	Application exceeding balance	Applied amount > remaining balance	Rejected (boundary/negative test)	H	Y
AP-PP-013	Application at exact balance	Applied amount = remaining balance	Allowed; balance to zero (boundary pass)	H	Y
AP-PP-014	Cross-currency application	Prepayment and invoice differ in currency	Conversion applied; FX handled correctly	M	Y
AP-PP-015	Missing conversion rate on application	Cross-currency, no daily rate	Application blocked / rate error	M	Y
AP-PP-016	Cross-business-unit restriction	Invoice BU ≠ prepayment BU	Blocked unless BU access permits	M	Y
AP-PP-017	Application to invalid supplier	Standard invoice for a different supplier	Prepayment not selectable (negative test)	H	Y
AP-PP-018	Tax treatment on prepayment creation	Taxable prepayment per tax setup	Tax calculated and accounted correctly	H	Y
AP-PP-019	Tax on application to invoice	Prepayment tax vs invoice tax rules	Tax handled per config; no double count	M	Y
AP-PP-020	Accounting date on application	Application in an open period	Entries posted to the correct period	H	Y
AP-PP-021	Application in a closed period	Application date maps to closed period	Blocked / re-dated per rules	H	Y
AP-PP-022	Cancellation before payment	Prepayment validated, not paid	Cancelled; accounting reversed	M	Y
AP-PP-023	Cancellation attempt after payment	Prepayment already paid	Cancellation blocked (negative test)	M	Y
AP-PP-024	Unapplication restores balance	Prior application exists	Invoice and balance both reinstated	H	Y
AP-PP-025	Reapplication after unapplication	Balance restored by unapply	Re-applied cleanly; balance accurate	M	Y
AP-PP-026	Prepayment vs credit-memo interaction	Invoice has both a prepayment and credit memo	Net amount correct; no interference	M	Y
AP-PP-027	Supplier-refund interaction	Unapplied balance recovered as refund	Refund reduces balance; accounting correct	M	Y
AP-PP-028	Reversal accounting entries	Application reversed	Offsetting balanced entries posted	H	Y
AP-PP-029	Integration-created prepayment	Prepayment created via REST / FBDI	Behaves identically to UI-created	M	Y
AP-PP-030	Approval workflow on prepayment	Amount above approval threshold	Routed and approved by correct rule	M	P
AP-PP-031	Role access for apply / unapply	User without the privilege	Action denied (SOD protection)	H	P
AP-PP-032	Duplicate-prepayment control	Same supplier + number as existing prepayment	Duplicate prevented / flagged	M	Y
AP-PP-033	Reporting & reconciliation of balances	Mix of open and consumed prepayments	Report ties to prepaid-advances GL account	M	Y
AP-PP-034	Quarterly-release regression pack	Post-update tenant	All prior prepayment results reproduce	H	Y

Pri = priority (H/M/L). Auto = automation candidate (Y suitable · P partly, needs role/data setup). Steps summarised; full step detail ships in the downloadable workbook.

Common Prepayment Defects

Defect	Likely cause	Business impact	Recommended test
Prepayment not applied	Process step missed before payment	Supplier paid twice	AP-PP-009, AP-PP-010
Balance not decremented	Application posts without updating balance	Over-application; overstated advances	AP-PP-011, AP-PP-013
Applied before available	Availability gate not enforced	Credit taken on unfunded advance	AP-PP-007, AP-PP-008
Over-application accepted	Balance ceiling not checked	Negative invoice; reconciliation break	AP-PP-012
Permanent offered for application	Type flag ignored	Advance mis-classified	AP-PP-002
Cross-currency mis-conversion	Wrong or missing rate on application	FX gain/loss mis-stated	AP-PP-014, AP-PP-015
Tax double-counted	Tax applied on both prepayment and invoice	Tax over-statement; compliance	AP-PP-018, AP-PP-019
Unapplication doesn't restore balance	Reversal updates invoice only	Balance lost; audit break	AP-PP-024, AP-PP-025
Cancellation after payment allowed	State check missing	Improper reversal of a paid advance	AP-PP-022, AP-PP-023
Closed-period application posts	Period check bypassed	Failed accounting; close block	AP-PP-020, AP-PP-021
Applied to wrong supplier / BU	Scope restriction not enforced	Mis-allocated advance; control gap	AP-PP-016, AP-PP-017
Balance report vs GL mismatch	Sub-ledger not reconciled to GL	Unexplained prepaid balance	AP-PP-033

How SyntraFlow Automates Prepayment Testing

SyntraFlow drives the full prepayment lifecycle — create, pay, apply, unapply, reverse — across the UI and API, then asserts the remaining balance and the accounting produced at each step, not just that the action completed.

Reusable prepayment components

Parameterised building blocks for create, pay, apply, unapply and reverse that you compose into your own lifecycle tests.

Dynamic supplier & invoice data

The Oracle Data Vault provisions eligible suppliers, sites, and standard invoices so each application test has the data it needs.

Application & balance validation

Asserts the remaining balance after every partial and full application — the difference between a real test and one that only clicks Apply.

Accounting evidence

Captures the journal entries for creation, payment, application, unapplication and reversal as audit-grade evidence.

UI and API execution

Runs prepayment flows through the Redwood UI and through REST, confirming both entry points produce the same balance and accounting.

Negative-path testing

Exercises over-application, pre-availability application, wrong supplier/BU, and post-payment cancellation, asserting each is refused.

Regression after setup changes

Re-runs the prepayment pack after supplier, tax, or invoice-option changes so drift is caught before it reaches production.

Self-healing execution

Runs re-anchor when Oracle redesigns the invoice or prepayment pages, so application and balance assertions keep working.

Release-impact selection

Runs only the prepayment subset a given release or configuration change actually affects.

A note on capability. Reusable lifecycle components, balance and accounting assertions, UI/API execution, negative-path testing, and evidence capture are current platform capabilities. Coverage scoped to your specific prepayment types, tax rules, and role model is configurable during onboarding. Deeper reporting-reconciliation automation is on the roadmap and is confirmed at assessment rather than presented here as live.

Prepayment Accounting & Reconciliation Checks

Every lifecycle event posts through Subledger Accounting, and the prepaid-advances balance must always tie back to the General Ledger. These checks confirm the money is where the balance says it is.

Event	Accounting expectation	Reconciliation check
Prepayment payment	Prepaid-advances (asset) debited; cash/liability credited	Advance balance increases by paid amount
Tax on prepayment	Recoverable/non-recoverable tax posted per rules	Tax accounts agree with tax reports
Application to invoice	Prepaid-advances credited; invoice liability reduced	Advance balance decreases by applied amount
Partial application	Proportional entry for applied portion only	Remaining balance = paid − sum of applications
Unapplication	Application entry reversed	Advance balance restored to pre-application value
Cross-currency application	FX gain/loss recognised on conversion	Realised FX ties to rate difference
Cancellation / reversal	Offsetting balanced entries in the correct period	Net effect on advance account is zero
Period-end position	Open prepayments carried at remaining balance	Sub-ledger prepaid total = GL prepaid account

For how these entries are generated and validated downstream, see Oracle Invoice Accounting Testing.

When to Re-Test Prepayments

Prepayment behaviour depends on supplier setup, tax, invoice options, and periods, so any change to those is a regression trigger. Retest when these events occur:

Change event	Risk to prepayments	Recommended regression scope
Oracle quarterly update	Application or accounting logic changes	Full prepayment pack, release-scoped
Redwood rollout	Prepayment / application UI changes	UI application + balance-display cases
Invoice / Payables options	Prepayment behaviour changes	Creation, availability, application cases
Tax setup change	Prepayment tax handling shifts	Tax-on-creation and tax-on-application cases
Supplier / site setup change	Eligibility and defaults change	Eligibility + supplier-scope cases
Currency / rate configuration	Cross-currency conversion changes	Cross-currency application cases
SLA / accounting rule change	Prepayment entries mis-derive	Accounting & reconciliation cases
Approval / hold rule change	Prepayment routing changes	Approval-workflow cases
Security-role change	Who can apply/unapply changes	Role/SOD application cases
New BU / ledger / legal entity	Cross-BU restrictions differ	Cross-BU + eligibility cases
Integration / API change	API-created prepayments diverge	Integration + parity cases

Prepayments & Oracle Quarterly Releases

Oracle's quarterly updates can change how prepayments apply or account without any action on your part — through feature opt-ins, Redwood redesigns of the invoice and prepayment pages, altered application rules, or tax changes. Because a prepayment carries a balance across periods, a silent change can quietly mis-state advances until a reconciliation surfaces it.

Rather than re-running every prepayment scenario each release, SyntraFlow Release Intelligence narrows the work to what actually changed in your tenant:

1.Analyses the Oracle release notes for changes touching prepayments and their application.
2.Maps those changes to your configuration — invoice options, tax, and supplier setup.
3.Identifies the prepayment types and business units affected.
4.Recommends the specific prepayment test cases to run.
5.Prioritises regression execution by balance and accounting risk.
6.Tracks application and accounting evidence for audit and sign-off.

See how the impact map is built on the Release Impact Analysis page.

Configurations That Drive Prepayment Behaviour

A prepayment test is only trustworthy if the configuration behind it is known and stable. Invoice and Payables options govern whether prepayments are enabled and how they apply; tax setup drives recovery; supplier and site setup gate eligibility; and period and currency configuration decide when and how application posts. When these drift between environments, a passing test can reflect the wrong reality.

SyntraFlow's Configuration Intelligence compares these setups across environments and flags drift before it corrupts a prepayment test result — so a passing balance means the configuration was correct, not merely present. Supplier-eligibility and site defaults are covered in more depth on Oracle Supplier Testing, and the validation that a prepayment passes on entry is covered on Oracle Invoice Validation Testing.

Free resource

The Oracle Prepayment Testing Workbook

A practical companion for building your own prepayment coverage. The workbook walks through the temporary and permanent prepayment types, the application rules that govern when a balance can be used, and the test data each case needs — the eligible suppliers, sites, and standard invoices that make an application test repeatable.

For each lifecycle event it sets out the expected remaining balance and the accounting outcome to assert, and closes with an evidence checklist for audit and sign-off. Use it to turn the scenario table above into a runnable pack scoped to your configuration.

Request the Workbook

Related Oracle Payables Pages

Prepayments connect to the rest of the AP suite. Go deeper on adjacent topics:

Supplier Site Testing →

Site config, defaults and controls.

P2P End-to-End Testing →

Supplier-to-GL Procure-to-Pay.

Oracle Payables Testing Tool ⭐

The AP testing hub.

Invoice Validation Testing →

Holds, distributions, and tolerances.

Payments Testing →

Disbursement behaviour and methods.

Payment Processing Testing →

Payment batches, PPRs, and bank files.

Invoice Accounting Testing →

Entries created after each event.

Supplier Testing →

Supplier and site eligibility.

Frequently Asked Questions

What is a prepayment in Oracle Payables?

▼

A prepayment is a special invoice type that records an advance paid to a supplier before goods or services are delivered. Once paid and past its settlement date, its unapplied amount is held as an available balance that can be applied to later standard invoices from the same supplier, reducing the amount due without a second cash disbursement.

What is the difference between a temporary and a permanent prepayment?

▼

A temporary prepayment is intended to be applied against future invoices and carries a running available balance. A permanent prepayment is an outright payment that is never applied — for example a non-refundable deposit. Testing must confirm a temporary prepayment can be applied and a permanent one is excluded from the application flow entirely.

When does a prepayment become available for application?

▼

A temporary prepayment becomes available only after it is fully paid and its settlement date has passed. Tests should confirm that an application attempt before either condition is met is blocked, and that the full balance opens for application exactly once both conditions hold.

How does prepayment testing differ from payment processing testing?

▼

Prepayment testing covers the advance's own lifecycle — creation, availability, application, unapplication, reversal, and its balance and accounting. The mechanics of disbursing it through payment batches, Payment Process Requests, and bank files are covered on the Payment Processing Testing page, so the two suites don't overlap.

What is the most important thing to assert in an application test?

▼

The remaining balance. It is not enough to confirm the Apply action completed — a real test checks that the standard invoice's amount due dropped by the applied amount and that the prepayment's available balance decreased by exactly the same figure. A balance that doesn't move is the signature of an over-application defect.

Can a prepayment be applied to more than one invoice?

▼

Yes. A single prepayment balance can be applied across several standard invoices from the same supplier until it is consumed. Tests should apply partial amounts to multiple invoices and confirm the balance decrements correctly after each, and that the prepayment shows fully applied once the balance reaches zero.

What happens if you try to apply more than the available balance?

▼

Oracle should reject an application that exceeds the remaining balance. This is a boundary test: applying an amount exactly equal to the balance should succeed and take the balance to zero, while one cent beyond should be refused. An accepted over-application produces a negative invoice and a reconciliation break.

How is unapplication tested?

▼

Unapplication reverses a prior application. The test must confirm two things happen together: the standard invoice's amount due is reinstated, and the prepayment's available balance is restored to its pre-application value. A common defect restores the invoice but not the balance, silently losing the advance.

Can a prepayment be cancelled?

▼

A prepayment can be cancelled before it is paid, which reverses its accounting. Once it has been paid, cancellation should be blocked — recovery of a paid advance is handled through unapplication and, where relevant, a supplier refund. Both the allowed pre-payment cancellation and the blocked post-payment attempt should be tested.

How is tax handled on prepayments?

▼

Tax may be calculated when the prepayment is created and then adjusted when it is applied, depending on your tax setup. The key risk is tax being counted twice — once on the prepayment and again on the invoice. Tests should validate tax at both creation and application and confirm the net tax is correct.

What about applying a prepayment in a different currency?

▼

When the prepayment and the standard invoice are in different currencies, application relies on the correct conversion rate and may recognise an FX gain or loss. Tests should cover a cross-currency application with a valid rate and a negative case where no daily rate exists, confirming the application is blocked or errors rather than converting incorrectly.

Can a prepayment be applied across business units or suppliers?

▼

A prepayment applies only to standard invoices for the same supplier, and cross-business-unit application is restricted by your BU access setup. Negative tests should confirm the prepayment is not selectable for a different supplier and is blocked across business units where it is not permitted.

How do prepayments affect month-end reconciliation?

▼

Open prepayments sit as a balance in the prepaid-advances account and must tie back to the General Ledger at period end. Testing the accounting for each event and reconciling the sub-ledger prepaid total to the GL account before close prevents an unexplained balance from stalling the reconciliation.

How often should prepayment testing be run?

▼

On every Oracle quarterly update, and after any change to invoice or Payables options, tax setup, supplier and site configuration, currency rules, or security roles. Because a prepayment carries a balance across periods, a silent change can mis-state advances until a reconciliation catches it — so regression after these events is worth the effort.