Independent IFS Cloud practice · Sales
The order that looks complete, and the tax code that was never set on it
A sales order line is meant to carry a tax code, which depends on the setup of the customer, the delivery address, and the part. When that setup is incomplete, a line can be entered with no tax code at all, or with one that does not match where the goods are going. The order can look finished and ship. Then the invoice either stops at posting or goes out with the wrong VAT, which is a correction with the customer or a problem with the tax authority. The tax code is stored on each line, so the lines where it is missing can be listed from the data.
Key takeaways
- The tax code on a sales order line depends on setup on the customer, the delivery address, and the part. If any of those is missing the relevant tax data, the line can end up with no tax code.
- A missing tax code surfaces late, at invoicing. Either the invoice can be blocked from posting, or it can post with a wrong or default rate, which becomes a VAT correction rather than a quiet fix.
- Lines with no stocked part behind them, where your setup allows such lines, have no part tax setup to take a code from, so check in your own data whether they can stay blank.
- This is a different gap from a line with no price. A line can have a correct price and still carry no tax code, so the two need separate checks.
- The tax code on each line, the delivery address, and the order state all live in IFS Cloud, so a read-only monitor can list the confirmed lines with a missing tax code before they reach invoicing, writing nothing back.
1.The tax code depends on setup, and setup can be incomplete
The tax code on a sales order line determines how the line is taxed on the invoice. It depends on the customer, the tax jurisdiction of the delivery address, and the tax setup on the part. When all three carry the data they should, a correct code can be applied to the line without anyone having to think about it.
The code can go missing when one input is incomplete. A new customer set up without its tax information, a delivery address in a jurisdiction that has no tax setup behind it, a part missing its tax handling, or a line with no stocked part behind it, where your setup allows one: each of these can leave the line without a tax code. Whether the order then stops depends on your setup. Where it does not, the line is confirmed, reserved, and shipped like any other, so check in your own data whether confirmed lines can carry a blank tax code.
So the gap is invisible right up to the moment of invoicing, which is the worst moment to find it. The goods are already with the customer, and the fix is now a tax correction rather than a field filled in before anything moved.
2.Lines where a missing tax code costs the most
A draft order still being built is not a problem yet. A confirmed line, close to delivery, with no tax code is a blocked invoice waiting to happen. The lines worth catching are the ones already committed to ship, because those are the ones where the gap turns into a customer-facing correction.
| What you see | What it points to |
|---|---|
| Confirmed line, near delivery, no tax code | The highest risk. The goods are about to ship and the invoice will either block or post wrong, so this is the one to fix before delivery. |
| Tax code present but inconsistent with the delivery jurisdiction | A code that derived from the wrong input, so the rate may be wrong even though the field is not blank. |
| Line with no stocked part and no tax code | A line with no part tax setup to take a code from, where the code was never set by hand and stays blank until invoicing. |
| A specific customer or address whose lines are repeatedly blank | A setup gap on that customer or delivery address, where every order will carry the same missing code. |
A confirmed line near delivery is where the disruption lands. The line reads as ready, the delivery is imminent, and no human has been told the tax code is missing. An order administrator working one order at a time cannot scan every open line for a blank tax field. Read across the confirmed lines, the short list is obvious.
3.Finding the confirmed lines with no tax code
The tax code on each line, the order and line state, the delivery address, and its tax jurisdiction are all available through standard OData projections, so they can be read without touching a record. Detection looks for two things:
- Confirmed line, tax code blank - lines that have passed order confirmation and are heading to delivery with no tax code set, so the ones that will stop or misprice at invoicing surface as a list.
- Tax code against delivery jurisdiction - lines whose tax code does not fit the jurisdiction of the delivery address as defined at scoping, so a code that derived from the wrong input ranks alongside the ones that are simply blank.
Because it is a read-only monitoring pattern, it runs beside order management and writes nothing back to IFS. It adds no object inside the client system, so an R1 or R2 release leaves nothing of ours in your IFS to retest. Before each release I check that the standard projections it reads still match, as part of the subscription. Setting the code, or fixing the customer or address behind it, stays with the order team. The monitor makes sure the team sees the lines with no tax code while the order can still be corrected, not after it is delivered and waiting to be invoiced.
4.Rolling it out without noise
- Start with confirmed lines near delivery - the lines about to ship are where a missing tax code turns into a blocked or wrong invoice, so watch those before drafts.
- Dry-run first - log which lines would have been flagged across a full period before a single alert reaches an order administrator.
- Cover lines without a stocked part - where your setup allows them, they have no part tax setup to take a code from, so include them in the check rather than assuming a code was set.
- Read only, no footprint - standard OData reads, nothing written back, no new object inside IFS Cloud.
Related reading
5.Frequently asked questions
Where does the tax code on a sales order line come from in IFS Cloud?
The tax code depends on the customer, the tax jurisdiction of the delivery address, and the tax setup on the part. When all three carry their tax data, a correct code can be applied to the line. When one of those inputs is missing its tax information, the line can end up with no code. Check in your own data which confirmed lines carry a blank tax code.
When is a missing tax code noticed?
Whether a missing tax code stops order confirmation, reservation, or shipping depends on your setup. Where it does not, the order flows through every step before invoicing, and the gap first shows when the invoice is created and posted. By then the goods may already have shipped, which turns a blank field into a tax correction with the customer.
Why do lines without a stocked part need their own check?
Where your setup allows a sales order line with no stocked part behind it, there may be no part tax setup for the tax code to depend on. The code then has to be set by hand on the line, and if it is not, it stays blank. Check in your own data whether such lines exist and whether any of them carry a blank tax code.
Does this monitoring write anything to IFS Cloud?
No. The tax code on each line, the line state, and the delivery address are read through standard OData projections and evaluated outside IFS. Nothing is written back, so there is no upgrade footprint and no new object inside the client system. Setting the code or fixing the customer setup stays a human decision.
6.About the author
Dariusz Myśliwiec brings 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who builds it.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Catch the tax code before the invoice, not after delivery
Tell me where a blocked or wrong invoice hurts you most. On a 30-minute fit call we check whether a rule that reads confirmed order lines and their delivery jurisdictions fits your data. The SCM Automation Pack runs three rules today (unconfirmed purchase orders, late deliveries, stock below minimum), so this would be an additional rule built to order, read-only, with a dry-run period before anything reaches an order administrator.