A purchase-order invoice usually has more on it than the goods you ordered. Alongside the line items for actual products, there's freight, sales or use tax, handling fees, surcharges, and other charges. They all belong on the invoice and all need to be coded and paid. But there's a category difference that AP workflows often ignore: you can physically receive the goods. You cannot physically receive a freight charge or a tax line.
That distinction sounds pedantic until you watch a goods-receiving step ask someone to confirm receipt of "freight — $42.00." The person at the dock sees boxes and has no idea what to do with a shipping charge that didn't arrive in a box. The result is hesitation, wrong answers, and matching errors that trace back to a question that should never have been asked.
Receivable versus non-receivable lines
The clean mental model is to split invoice lines into two groups:
- Receivable lines — the goods themselves. These correspond to PO lines that someone physically takes delivery of. They're the lines that participate in the receiving transaction and the three-way match.
- Non-receivable lines — freight, tax, handling, and similar charges. These are real costs that must be coded and paid, but there is nothing to physically receive against them. They have no quantity arriving on a dock.
Oracle's three-way match exists to confirm that what you were billed for is what you ordered and what actually showed up. That logic only makes sense for the receivable lines. Asking a freight charge to clear a quantity-received check is a category error — there's no quantity, and there's no receipt, because nothing was received.
What goes wrong when you don't filter them out
When non-receivable lines get pulled into the receiving step, the problems are immediate and avoidable:
- The receiver is confused. The person confirming delivery — often not an AP specialist, but a site bookkeeper or department staffer — is shown a line they can't act on. Do they "receive" the tax? Skip it? Guess? Any of those is friction at the dock, exactly what you're trying to remove.
- You manufacture false matching errors. If the workflow expects a receipt against a freight line, that line will never match cleanly, because no receiving transaction will ever exist for it. You've created a permanent exception out of a line that was always correct.
- Real exceptions get buried. When the queue fills with "unmatched" freight and tax lines that were never supposed to match, the genuine discrepancies — a real quantity shortfall, a price overage — are harder to spot in the noise.
Filter at the receiving step, keep the lines on the invoice
The fix is not to delete freight and tax — they have to be paid. The fix is to scope the receiving step to receivable lines only. When an invoice reaches goods receiving, the person confirming delivery should see exactly the lines that correspond to physical goods on PO lines, and nothing else. Freight, tax, and other charges stay on the invoice, get coded normally, and flow through to payment — they just don't appear in the "did this arrive?" question, because that question doesn't apply to them.
This keeps the three-way match honest. The receivable lines match against the PO and the receipt the way Oracle intends. The non-receivable lines are handled as what they are — costs to code and pay, not deliveries to confirm.
A couple of principles make this robust in practice:
- Identify non-receivable lines reliably. Freight and tax lines are distinguishable from goods lines — by line type, by the nature of the charge, or by how they map to PO lines. The workflow should recognize them up front and route them out of receiving automatically, not rely on the receiver to know the difference.
- Keep service and non-PO invoices out of receiving entirely. A service-only PO or a non-PO invoice has nothing to physically receive. Those should bypass the receiving step altogether, the same way freight and tax lines do.
- Don't drop the charges from matching where they belong. Freight and tax may still participate in two-way matching or tolerance checks against the PO. Excluding them from receiving isn't the same as excluding them from validation — they just don't pretend to be deliverable goods.
The payoff: a clean receiving step and a clean match
When the receiving step shows only what can actually be received, the whole flow gets simpler. The receiver answers a question that makes sense — "did these goods arrive?" — and answers it confidently. The three-way match runs against lines that are supposed to match, so it passes when it should and flags only genuine discrepancies. And the AP team isn't sifting through a queue of freight charges that were correct all along. Clean inputs to receiving mean a clean three-way match, which means fewer manufactured exceptions for AP to clear.
Where EZ Cloud fits
This is precisely the kind of detail that determines whether automated receiving reduces AP work or quietly creates new busywork. We filter non-receivable lines out of the goods-receiving step on Oracle EBS, so the receiver sees only the goods lines they can actually confirm — while freight, tax, and other charges stay on the invoice and flow through coding and payment as normal. It's built into our in-workflow goods receiving, where the person who took delivery confirms receipt without ever logging into Oracle Purchasing.
If your goods-receiving step is asking people to "receive" freight and tax — and your exception queue is full of lines that were never going to match — the fix isn't more matching rules. It's making sure receiving only sees what can be received.