The fiscal year ends. The invoices don't.
For public-sector finance teams — and for K-12 districts in particular — the calendar creates a recurring headache. The books close at year-end, but for weeks afterward AP keeps receiving invoices for goods and services that were delivered before the close. Those invoices belong to the year that just ended, not the one that just began. Charging them to the wrong fiscal year throws off the closing reports auditors and state regulators rely on.
This is the prior-year invoice problem, and on Oracle E-Business Suite it has a specific, well-worn solution that most generic AP automation tools have never heard of.
Why public-sector AP can't just "post it to this year"
In commercial accounting, a late-arriving invoice is usually an accrual or an immaterial timing difference. In government and education finance, it's a compliance matter. Public entities report fund-level spend against a closed fiscal year, and state oversight bodies expect that an invoice for goods received in the prior year lands in the prior year — full stop. The window where this matters is predictable: it opens at the start of the new fiscal year and runs for roughly two months while the prior year is finalized.
During that window, AP staff have to make a judgment call on every invoice: does this belong to the year that closed, or the new one? The judgment is based on the facts of the invoice — when the goods or services were actually delivered — not on the date the invoice happened to arrive.
How Oracle EBS already handles it
Oracle EBS has a long-established pattern for this. Many districts store a "prior year" designation on one of the descriptive flexfield attribute columns on the invoice header — typically a column like ATTRIBUTE3 on AP_INVOICES_ALL. A year-end closing report reads that column directly to pull every invoice tagged for the prior year onto the right side of the cutover.
It's a clean, native approach with one catch: somebody has to set the flag. In a manual process, an AP specialist opens each invoice in Oracle after it imports and sets the attribute by hand. That's fine when you're keying invoices directly into the ERP. It falls apart the moment your invoices arrive through an automation layer that has never been told the flag exists.
The gap automation creates — and how to close it
Here's the failure mode. You automate invoice capture and posting. Invoices now flow straight into Oracle untouched by human hands. That's the goal — except during the prior-year window, when every imported invoice now has to be re-opened in Oracle and manually re-flagged, because the automation passed it through without the attribute set.
You've automated AP and accidentally re-created manual work for two months a year. Worse, if a single invoice gets missed in that re-flagging step, it silently drops off the closing report and posts to the wrong fiscal year — exactly the compliance error the flag exists to prevent.
The fix is to teach the automation about the flag and let AP set it at the point of invoice entry, inside the workflow, before the invoice ever reaches Oracle:
- A prior-year field on the invoice header, visible to everyone in the workflow for transparency but editable only by authorized AP users, consistent with the organization's internal controls.
- No date gating. The field is always available; AP decides when to apply it based on the invoice's facts. Hard-coding a calendar window into software is brittle — the people closing the books know better than a date check does.
- Native pass-through on submission. When the flag is set and the invoice reaches final approval, the automation writes the expected value to the same attribute column the closing report already reads. Oracle's standard import program carries it through with no custom triggers, no report changes, and no new moving parts on the ERP side.
- An audit trail. The workflow records when the flag was set and by whom — something the manual post-import process never captured.
The elegance here is that nothing about Oracle changes. The closing report reads the same column it always read; automated invoices simply land in it correctly alongside any still keyed by hand.
Get it in place before July
The thing about this requirement is that it's seasonal and unforgiving. It doesn't matter for ten months of the year, and then for two months it matters on every single invoice. If you're standing up AP automation on Oracle EBS, the prior-year flag needs to be live and tested before the fiscal-year cutover, not discovered in the middle of it.
This is one of the public-sector specifics we built into K-12 AP on Oracle EBS, and it's part of why fund accounting breaks generic AP automation tools that were designed for commercial calendars. EZ Cloud captures the prior-year designation in the approval workflow and passes it natively into Oracle EBS — so a large US public school district can keep its year-end close clean without re-keying a single invoice.
If your fiscal year-end is approaching and your AP automation has no concept of prior-year invoices, that's a gap worth closing now. It's the kind of detail our Oracle EBS & Fusion integration was built to handle.