Payment Date Basis Decides Which Invoices Make It Into a Payment Run
Author : Vicky Blogs | Published On : 07 Oct 2026
Introduction
Picture two payment runs with the same payment date and pay-through date, where one picks up an invoice and the other leaves it behind. At Soft Online Training, we see this puzzle come up often in Oracle Fusion Financials Training in Pune, because the only difference is the date basis. Nothing looks wrong in either request.
That is why date basis is a real control decision and not an obscure template field. Before anyone submits a request, they should know which invoices will be selected and what discounts will apply. Without that, forecasting cash, capturing discounts, and explaining why an invoice was paid all become guesswork.
Three Dates That Answer Three Different Questions
Start by pulling apart the dates people tend to blur together. The payment date is when the organization intends to pay. The pay-through date is the latest point the run will reach when selecting installments. Then there are the installment's own due date and any discount dates its terms produce.
A run that pays everything due by Friday is a different animal from a run that captures every discount available through Friday. So write down the goal first. Is early payment allowed? How does treasury weigh holding cash against taking a discount? Once that's clear, set the dates and the basis to match it.
A small test calendar helps a lot here. For each sample invoice, note the invoice date, terms, due date, discount dates and amounts, the supplier site's pay date basis, the payment and pay-through dates, and the result you expect. Include an installment due exactly on the boundary, one due a day later, one with an earlier discount date, and one with no discount at all. Save weekends and holidays for later, since calendar adjustments can hide a wrong basis. Remember that "is it selected?" and "which discount applies?" are two separate questions.
What the Date Basis Actually Changes
Oracle's 26C documentation on date basis in payment process requests contrasts two behaviors. When the request uses Pay date as its basis, the supplier site's Pay Date Basis setting also influences which installments are selected and which discount is taken. When the request uses the Due date, selection is judged against the installment's due date. So an invoice due after the pay-through date can still join a discount-focused run under the right settings, while a due-date run will skip it.
This is exactly the sort of detail that gets a learner through a confusing exercise, and it's a core topic in any solid Oracle Fusion Financials Training in Pune program. The setting should follow approved working-capital policy. Nobody should flip it just because an expected invoice failed to show up.
Supplier sites deserve a close look too. Two suppliers can share the same terms and due dates and still behave differently because one site favors discount timing and the other follows due timing. Sometimes that's intentional, based on negotiated arrangements. Sometimes it's stale master data. Keep an owner and a change record for the setting. When someone reports a surprise, compare the request basis with the supplier-site basis before touching any dates. Then confirm the invoice is on the expected site with the expected terms, because a copied site or a late terms correction can change the calculated dates and make the run look inconsistent when it's simply working from different data.
Selection Criteria Work Together, Not One at a Time
Dates are only part of the picture. Business unit, legal entity, pay group, priority, supplier, payment method, currency, supplier type, and invoice group all narrow the pool of candidates. With centralized payments, service-provider relationships and access rights come into play as well.
Treat all of these as a single population statement: which obligations, owned by whom, paid from which operation, within what priority and date window, in which currencies. Checking one field at a time is how people miss the interaction that dropped an installment. A perfect date result means little if the request searched the wrong business unit or a pay group quietly filtered out the invoice you wanted.
Payment construction narrows things further. The internal bank account and the payment process profile bring their own rules about business units, currency, payment method, and usage. An installment that was happily selected can still fail later if those attributes don't line up. Aim for selection and payment building to describe the same executable population. It's worth testing a deliberately incompatible installment to confirm it stops where you expect, with enough information to fix it. And resist the urge to loosen bank-account or profile rules just to cut down on rejections. Those rules often reflect legal ownership, funding, file format, and authorization boundaries that need their own approval.
Review Stops Are Only Useful If Someone Decides Something
Installment review earns its keep when a run is new, unusually large, sensitive to discounts, or built on changed criteria. Reviewers should compare counts and amounts against expectations by business unit, legal entity, currency, supplier, due-date band, and discount outcome. Sample the boundary cases, not only the biggest invoices.
The proposed-payment review does a different job. It lets the team look at grouping, bank account, payment method, and the resulting payments once selection is done. Decide in advance who can add or remove items, which reasons are acceptable, and when a changed population needs fresh approval. Without those criteria, a review screen turns into a ceremonial pause before an immediate release.
Exceptions should keep their context. For a missing invoice, capture the request name, criteria, both date bases, installment dates, holds, payment status, business unit, currency, method, and profile compatibility. Do the same for an unexpectedly selected invoice before removing it. That way another analyst can reproduce the outcome and tell configuration problems apart from transaction data problems.
Watch for patterns, too. If people keep pulling out not-yet-due invoices, the horizon or discount policy may be too aggressive. If they keep adding invoices by hand, the criteria may be too narrow, supplier terms may be wrong, or urgent invoices may be arriving after the cutoff. Each cause needs its own fix.
Rehearse Before You Schedule: Practical Steps for Oracle Fusion Financials Training in Pune Learners
Before scheduling a template, run a labeled test set through both date-basis options in a nonproduction environment. Include exact-boundary due dates, multiple discounts, expired discounts, installments beyond the pay-through horizon, zero-amount invoices if they matter to you, a mix of priorities, and some incompatible currencies or methods. Record what you predicted against what happened for selection, discount, rejection stage, and final payment grouping. Then change one supplier-site basis and rerun the same set. That side-by-side comparison teaches far more than a handful of screenshots.
After go-live, keep comparing expected cash and discount totals with actual payments. Drift tends to appear after term changes, acquisitions, calendar updates, or template maintenance, so check then.
Conclusion
Payment date basis decides how a payment request reads its time horizon, and supplier-site settings can quietly change which invoices get paid. A solid runbook, built on the job or learned through Oracle Fusion Financials Training in Pune, keeps the payment date, pay-through date, due dates, and discount dates apart. It names the cash goal, looks at all selection criteria together, and matches bank-account and profile rules to the same invoices.
Run boundary tests before you schedule any template, and check both selection and discount results. Keep a note of every invoice added, removed, or missing. When your team can explain why each installment made it into a run, payments become a decision you can defend.
