Oracle Payment Terms Testing

Payment terms control when an invoice is due, whether an early-payment discount applies, and how the invoice is split into instalments. Oracle applies the term against the invoice's terms date to calculate a due date, a discount date, and a scheduled-payment row for each instalment. Those dates then drive when the invoice becomes eligible for a payment run.

Payment terms testing verifies how due dates, discounts and instalment schedules are calculated and how terms default onto invoices. Payment processing testing covers what happens next — payment selection, batches, format and file generation, and bank execution. Terms produce the dates; processing acts on them. See the payment processing page for the run itself.

Oracle resolves the term through a defaulting hierarchy: a manual override on the invoice takes precedence, then the purchase order on a matched invoice, then the supplier site, and finally the supplier. Each level needs its own test because a change at one level can be masked by another, and defaulting defects usually trace back to supplier or site setup.

The terms date is the base date from which the term calculates the due and discount dates. Depending on your Payables and invoice options, it can be the invoice date, the received date, the goods-received date, or the system date. Because the same term produces different due dates on different bases, each basis needs its own test.

Assert three things: the due date is the terms date plus 30 days, the discount date is the terms date plus 10 days, and the discount amount is 2% of the discountable base. Then test both sides of the window — a pay date inside it captures the discount, one after it does not. Multi-level terms need the correct tier to apply for each candidate pay date.

Verify each instalment row's due date and amount, confirm the split proportions are correct, and check that the sum of all instalments equals the invoice gross to the cent — including the placement of any rounding remainder. Odd amounts split three ways are a classic source of a one-cent imbalance that only a total-reconciliation assertion catches.

Proximo and day-of-month rules involve a cut-off day and a month rollover, so an off-by-one setup can push a due date a full month early or late. Short months, leap years, and terms dates that land exactly on the cut-off day are the boundaries where these rules break, which is why they warrant dedicated boundary tests.

Only if a payment calendar is configured to shift due dates off non-working days. Whether adjustment happens depends on your setup, so tests should confirm the actual behaviour rather than assume it — a calculated due date on a weekend or a defined holiday should either stay or shift exactly as your calendar dictates.

If the terms date is based on the invoice date, editing the invoice date before validation should recalculate the due and discount dates. A test should confirm the schedule recomputes rather than retaining stale dates — a term override that fails to trigger recalculation is a common defect that leaves the wrong dates in place.

An end-dated (inactive) term should no longer be available to default or select, and a term whose start date is in the future should not be applied before that date. Negative tests confirm Oracle enforces validity so a retired or not-yet-active schedule cannot slip onto an invoice unnoticed.

Indirectly but decisively. The calculated due date defines the pay-through window a payment run reads, and the discount date defines the early-pay window. Terms testing confirms those inputs are correct; the actual selection against a pay-through date is exercised in payments testing. A validated invoice is also a prerequisite for selection.

A credit memo carries its own term and schedule, and the sign and dates must be correct so it offsets payments at the intended time. A prepayment applied to an invoice reduces the amount that flows into the remaining schedule. Both are worth explicit cases because the calculation interacts with document type, not just the term definition.

On every Oracle quarterly update, and after any change to term definitions, the terms-date basis, Payables or invoice options, the payment calendar, or supplier and site assignments. Because a wrong due date is silent and affects cash timing, testing after these events protects against drift that would otherwise surface only when an invoice pays early or late.

Yes. Invoices loaded through FBDI or REST can supply or derive a term differently from manual entry, producing due dates that diverge by channel. A complete suite tests that an imported invoice ends up with the same term and schedule the UI defaulting would produce, so the entry channel does not silently change cash timing.

Each test needs a supplier or site carrying a known term, an invoice with a controlled terms date, and — for defaulting and matched cases — a purchase order. SyntraFlow's Oracle Data Vault provisions this data so each date scenario runs against clean, known values and the expected due date, discount date and instalment schedule are unambiguous.