Most AP automation talks about the invoice as a single object: extract the header, validate it, post it. But the costly errors often hide a level deeper — inside the lines. An invoice can clear duplicate detection, supplier validation, and PO matching, and still post wrong, because a freight charge or a project-coded line wasn't handled the way Oracle Fusion Cloud ERP needs it to be.
These line-level cases are easy to wave away as edge cases. They're not. Get them wrong and the invoice still posts — which is exactly why they're dangerous. Nothing fails loudly. Your freight reporting and project accounting just quietly drift away from reality, and you don't find out until someone reconciles months later.
Freight: a charge that has to stand on its own
Freight and delivery charges show up constantly — often buried as an extra line, or tacked onto the bottom of an invoice that's otherwise all goods. The instinct of a naive tool is to treat that line like every other line and code it to the same account as the items above it.
That's wrong for two reasons. Freight is usually accounted for separately from the cost of the goods, and lumping it into the goods lines makes both numbers wrong — you over-state the goods cost and lose visibility of what you're spending on freight. So the correct handling is to split the freight charge out as its own distinct invoice line, with its own distribution, before the invoice proceeds through standard processing.
Done right, this is invisible to the AP officer — the system recognizes the freight line, separates it automatically, and the invoice flows on. Done wrong, it's invisible too, until freight spend can't be reported because it was never recorded as freight.
Project and WIP lines: coding to capital, not expense
The second case is higher-stakes. When an invoice line carries a project code, it usually shouldn't post to a standard expense account at all. It belongs in work-in-progress (WIP) — accumulating against a project or capital job rather than hitting the period's expenses.
This matters because the accounting treatment is fundamentally different:
- An ordinary expense line hits the P&L in the period it posts.
- A project/WIP line accumulates on the balance sheet against the job, to be capitalized or settled when the project completes.
Code a project line as a plain expense and you've mis-stated both the period's expenses and the project's cost — two errors from one missed flag. The right behaviour is to detect the project code on the line and adjust the distribution to post to the WIP account before the invoice continues through standard processing.
Why this is a line-level decision, not a header one
The reason these cases are hard for generic OCR tools is that they live below the level most automation reasons about. Header-level validation — is this a duplicate, is the PO open, is the supplier valid — treats the invoice as one thing. But freight and project coding are per-line decisions:
- A single invoice can have ordinary goods lines, a freight line, and a project-coded line, all at once.
- Each line needs its own routing: goods to their expense account, freight split to its own distribution, the project line to WIP.
- The header can be flawless while the lines are mis-coded — so checking only the header guarantees nothing about whether the invoice posts correctly.
Real line-level handling means reading each line, recognizing which special case it falls into, and building the right Fusion distribution for it — then letting the invoice flow on through the normal path. The clean lines post the ordinary way; the special lines get the treatment they need without a human having to catch them by hand.
These two are part of the broader taxonomy a healthcare AP team works through on every invoice — the full set of invoice scenarios on Oracle Fusion. Like PO-status checks and partial-receipt validation, the principle is the same: correct automation is about doing the right thing with each part of the invoice, not just reading it.
Why healthcare hits this often
Health services run a lot of capital and project work — building and fitting out facilities, deploying clinical equipment, IT and infrastructure programs — all of which generate project-coded invoices that have to land in WIP, not expense. And the supply chain for physical goods means freight rides along on a steady share of invoices. So both line-level cases turn up routinely, mixed into the ordinary flow, where they're easy to miss one at a time and expensive to discover in aggregate.
Where EZ Cloud fits
EZ Cloud handles these at the line level: it recognizes freight charges and splits them out as their own distribution line, detects project-coded lines and codes them to the work-in-progress account, and lets the ordinary lines post the standard way — all building the correct Oracle Fusion distribution before the invoice proceeds. The freight that used to vanish into goods cost gets recorded as freight; the project spend that used to hit the P&L lands in WIP where it belongs.
This is part of how we process the full variety of a real AP inbox for healthcare finance teams running Oracle Fusion, posting through Oracle-supported integration methods. You can see how that's built on our Oracle EBS and Fusion integration page.