The business impact of implementing IFS Cloud ERP

FndMig and DMM validate what they can define a rule for: mandatory fields populated, foreign keys resolving to a record that exists at the moment the load runs, values within a domain the target field accepts. Mandatory-field and foreign-key checks catch errors that are structurally invalid outright, at load time, with a log line pointing at the offending row. What it structurally cannot catch is anything that is syntactically and referentially valid but semantically wrong: a quantity that is a legal number, just computed from the wrong conversion factor; a foreign key that resolves correctly today because the parent happened to load in an earlier batch, even though the two were never meant to be linked; a value hand-patched into a staging spreadsheet under time pressure and never checked against the rule it was meant to satisfy.

None of that trips a validation rule, because none of it is invalid data. It is valid data that means the wrong thing, and the tooling has no way to know what the right thing was supposed to be without someone writing and maintaining that rule deliberately, on top of the standard load, not instead of it.

Unit-of-measure conversion mismatches are the failure I see most often and trust least in any migration I inherit rather than build myself. The legacy system holds a quantity in one unit, the legacy source data was extracted with an assumed conversion factor to the target stocking unit, and that factor was either wrong, out of date, or applied inconsistently across the extract. The load itself is completely happy: it sees a numeric quantity, it sees a valid unit of measure on the part record, it writes the value. Nothing about the transaction is invalid.

What actually happens is that the on-hand balance loaded into IFS is now arithmetically consistent and physically false. It will not surface at go-live, because nobody is comparing the freshly loaded balance against a physical count on day one. It surfaces at the first cycle count, or worse, the first time someone tries to ship an order against that balance and the pick fails or, more dangerously, succeeds against stock that is not really there in that quantity. By the time it surfaces, the legacy system is usually decommissioned, the original extract is gone, and reconstructing the correct conversion factor means going back to the part’s technical specification or, in the worst case, physically recounting everything affected.

The check that catches this before go-live is uncomfortably simple and rarely done under deadline pressure: for a sample of parts across every unit-of-measure pairing in the extract, not just the high-value ones, physically verify the conversion factor against the part specification, independently of whatever factor the extract used. If the legacy system and the target system disagree on the factor for even one pairing, assume every part using that pairing is suspect until proven otherwise, not just the one you happened to sample.

A migration runs in a sequence, dependent objects loading after the parents they reference. The failure mode here is subtler than a broken foreign key rejected at load time. It is a foreign key that resolves successfully, at the moment its record loads, to a parent record that exists in the target system for reasons entirely unrelated to being the correct parent: a batch that loaded slightly out of the intended order, or a mid-project dedup pass that consolidated two legacy IDs into one target record without updating every child reference to match.

The record is not invalid, it just does not point at the thing it was supposed to point at, and load validation, which only checks that a referenced key exists at the moment of the load, has no way to know that. It tends to surface in one of two ways: a report that silently pulls the wrong parent’s attributes for months before anyone notices, or a downstream process that fails in a way that looks unrelated to migration at all, which is what makes it expensive to trace back to its actual cause.

The mitigation I now insist on is a post-load reconciliation pass that is separate from load-time validation: after the full sequence completes, re-walk every parent-child relationship that matters for the modules in scope and confirm each child’s parent is the one the source system actually recorded, by comparing legacy identifiers carried through as cross-reference fields, not by trusting that the target key resolving at all means it resolved correctly. This has to run after the whole sequence, not batch by batch, because the specific failure pattern is a batch ordering issue that a single batch’s own validation cannot see.

Every migration I have worked on has had at least one point where the automated extract could not resolve something cleanly under the schedule available, and someone hand-corrected a batch of rows in a spreadsheet before feeding them into the load. This is not a criticism; it is sometimes the only realistic way to hit a cutover date. The failure is that the patch is applied once, works, and then nobody schedules the work to fold the correction back into the repeatable extract logic, because the project has already moved on to the next milestone.

The specific way this bites later is not usually the patched data itself going wrong; a careful hand-correction is often more accurate than the automated logic it replaced, at the moment it was made. It is that the underlying source data changes after go-live, a new batch of the same record type arrives through the same integration or a delta load, and the extract logic that was never fixed reproduces the original error on the new records, because nobody remembers, months later, that this particular field needed a hand adjustment and why. The knowledge lived in a spreadsheet on someone’s laptop, not in the transform logic, and the spreadsheet is gone or forgotten well before the problem resurfaces.

What I do differently now: every hand-patch gets a one-line entry in a migration decisions log, at the moment it is applied, stating which field, which record population, what the automated logic got wrong, and what the correct rule actually is. That log is the input to a follow-up task, tracked separately from go-live, to either fix the transform logic properly or, at minimum, confirm in writing that the condition causing the original error cannot recur post-cutover. A patch without that entry is indistinguishable, eighteen months later, from a deliberate design decision, and someone will eventually build on top of it assuming it was one.

Four checks catch this class of error after any load I am responsible for: conversion-factor consistency, parent-child cross-reference matching, patch-window edits and an independent-source quantity comparison. They are shown here as generic, PL/SQL-flavoured pseudocode using aliases rather than an assertion about a specific release’s exact schema, because the exact objects involved differ by module and by release:

None of these queries are complicated. What matters is that they run as a separate step after the load, not folded into load-time validation, because the point is to catch things that were valid at load time and wrong in a way that only shows up when compared against something outside the load itself.

1. Sample and independently verify conversion factors before the first mock load. Do this against the part specification, not against the extract's own assumptions, and treat any disagreement as a signal to check the whole unit-of-measure pairing, not just the sampled parts.
2. Run the post-load parent-child reconciliation after every mock load, not just the final one. Catching an orphan pattern in mock load two, while the extract logic is still being actively worked, is far cheaper than catching it after go-live.
3. Keep a live migration decisions log from day one. Every hand-patch gets an entry the day it is applied, not retroactively at project close-out when nobody remembers the details.
4. Assign an owner and a deadline to each logged patch. A decision log nobody is accountable for closing out is just documentation of a problem that still exists.
5. Run the independent-source quantity check at every mock load and at go-live. Comparing against the legacy system's own totals, not just internal consistency within the new load, is what catches a systematic conversion error rather than a one-off.
6. Freeze the decisions log and confirm every open item before cutover. An unresolved “temporary” patch at cutover needs an explicit, written decision to accept the risk, made by someone who can actually own that decision, not a default of silence.
7. Wire the same reconciliation queries as a recurring Custom Event check for the first few months post-go-live. New data flowing through the same integration paths can reproduce a migration-era error long after the migration project itself has closed, and a standing check inside the Extensibility Framework catches that far earlier than the next audit would.

Dariusz Myśliwiec: 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud), including Data Migration Manager, FndMig and Oracle PL/SQL work across those projects. IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice.

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.

A standard duplicate check compares the incoming invoice’s supplier reference against references already recorded for that supplier and flags an identical string. It runs at invoice entry or on import, and where it fires it is genuinely useful: it stops the case where the same document, unaltered, is keyed or scanned in twice. The problem is that this is the least common way a real duplicate actually enters the system.

In practice, most real duplicates carry a reference that is close to, but not identical to, the one already on file. A supplier’s AP clerk re-keys the invoice by hand after an EDI feed silently failed, and mistypes one character. The same invoice arrives twice through two different intake channels, an email attachment and a supplier portal upload, and each channel’s OCR or parsing step normalises the reference slightly differently, one keeping a leading zero, the other stripping it. A supplier resubmits after a query, appending “-R” or “REV1” to the original reference to indicate a revision, when in substance nothing about the underlying charge changed. In every one of these cases, a string-exact comparison sees two different values and passes both invoices straight through to payment.

A workable fuzzy match cannot rely on any single signal in isolation. Each dimension on its own either produces overwhelming noise or misses the cases exact match already misses:

• Supplier. Restricting comparison to invoices from the same supplier account is the cheapest and most defensible filter, and it should always be the outer boundary of the search rather than scanning the whole ledger.
• Amount, within a small tolerance. Comparing amount alone within a supplier will flag every recurring subscription or standard-rate service invoice as a near-duplicate of the last one, so amount only earns weight when combined with the other three signals, not on its own.
• A bounded date window. Two invoices from the same supplier for a similar amount six months apart are almost certainly unrelated; the same pairing inside a window of a few days to a couple of weeks is a meaningfully different signal and deserves scrutiny.
• A normalised reference. Not an exact string match, but a comparison after stripping punctuation, leading zeros, whitespace and known channel-specific prefixes or suffixes, then measured with a similarity function such as edit distance rather than equality.

The combination matters more than any individual threshold. A pair that scores high on three of the four dimensions and weak on the fourth is a stronger candidate for review than a pair that scores moderately on all four, and a rule that simply sums independent scores without weighting the reference-similarity signal more heavily tends to under-flag the cases that matter most: same supplier, same amount, close date, and a reference that is clearly the same invoice retyped.

The pattern below is illustrated as generic, PL/SQL-flavoured pseudocode using aliases rather than an assertion about a specific release’s exact schema, intended to show the shape of the join and the scoring logic rather than exact field names:

A pair that satisfies the supplier, amount and date conditions and clears the reference-distance threshold is a hold candidate, not an automatic block. The distinction matters operationally: an automatic block on a fuzzy match, unlike an exact match, will eventually catch a legitimate near-match and stop a real payment, so the rule should route to a review queue with the matched pair shown side by side, not silently reject the second invoice.

A credit-and-rebill pair is the single most common false positive a fuzzy matcher generates once it starts working well enough to catch real duplicates. A supplier issues a credit note against an incorrect invoice and then reissues a corrected invoice for the same or a very similar amount, from the same supplier, usually within days. On supplier, amount and date alone, this pair is indistinguishable from a genuine duplicate. It is only distinguishable because one document is a credit, carrying a negative amount or a distinct document type, and the other is a standard invoice, and because the reference on the credit note typically points back at the original invoice it is correcting rather than resembling the reissued one.

A rule that compares absolute amount without checking sign, or that does not filter by document type before scoring reference similarity, will flag this pair every time, and it will do so for one of the more routine, legitimate exception flows in accounts payable. The fix is not a looser threshold, it is an explicit document-type and sign condition ahead of the fuzzy comparison, as shown in the last row of the table above.

A second, subtler near-match worth excluding deliberately is a recurring service invoice with a genuinely stable amount, a maintenance contract or a subscription billed monthly at an identical rate. Two consecutive months of an identical amount from the same supplier will satisfy the amount and date conditions trivially. What separates it from a duplicate is that the reference itself changes predictably, an incrementing invoice number or a period-coded suffix, and a normalisation step that strips the wrong part of that reference, the incrementing digit rather than a formatting artefact, will accidentally collapse two genuinely different invoices into a false match. Normalisation rules need to be tuned per reference format, not applied as one blanket regular expression across every supplier.

1. Start with the exact-match population and measure its recall. Run the existing exact check against a sample of known real duplicates found manually or through an audit, and confirm for yourself how few it actually catches before proposing anything more complex.
2. Profile the reference formats in use, per supplier. Reference conventions vary widely: some suppliers zero-pad, some prefix with a site or division code, some append revision suffixes. A single global normalisation pattern will underperform a small set of supplier-specific rules.
3. Set the amount tolerance and date window from real data, not intuition. Look at the time gap and amount delta on genuine historical duplicates you can identify, and size the thresholds around what actually occurred rather than a round number that feels safe.
4. Add the document-type and sign exclusion before scoring reference similarity. This single condition removes the largest source of false positives, as covered in section 4, and should not be treated as an optional refinement added later.
5. Route matches to a review queue, not an automatic block. Present the candidate pair side by side with both amounts, dates and references visible, and let a human confirm before anything is held from payment.
6. Track the override rate by reviewer and by supplier. A high override rate on a specific supplier usually means that supplier’s reference format needs its own normalisation rule, not that the whole detector needs loosening.
7. Wire the confirmed-match logic to a Custom Event on invoice entry. Once thresholds are tuned against real data, the same scoring logic can run at the point of entry rather than as a periodic batch report, catching a likely duplicate before it is approved for payment rather than after, built inside the Extensibility Framework against the standard supplier invoice entity.

Dariusz Myśliwiec: 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 through an independent practice.

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.

In IFS Cloud a sales order line takes a price, usually from a price list, an agreement, or a manual entry. Normally that price is present and correct before the line is released. The gap opens when the price resolves to zero or nothing: a new part has no price list entry, an agreement expired and nothing replaced it, a manual line was entered in a hurry, or a configuration returned a zero the person entering the order never noticed.

None of these blocks the order. The line has everything the warehouse needs, so it picks, packs, and ships, and the price, or its absence, is nobody’s job at that point. The order moves to invoicing carrying a value of zero, and unless someone reads the price before the goods leave, the first time the gap is visible is on an invoice that asks the customer for nothing.

The cost is revenue given away, plus the awkward job of asking a customer to pay for something you already told them was free.

• Free goods: a line billed at zero hands the customer product at no charge, and the money is gone the moment it ships.
• Awkward retro-billing: recovering the revenue means invoicing after the fact for goods the customer received believing they were free, which invites a dispute.
• Distorted margin: a zero-value line drags reported margin and makes a product or customer look far less profitable than it is.
• Control gap: goods leaving with no price is a straightforward finding for anyone reviewing revenue completeness.

A wrong price gets queried by a customer who thinks they were overcharged. A zero price gets queried by no one, because the customer is delighted and you are the only one out of pocket. That is why it lasts until a reconciliation catches it.

Illustrative only: one low-value line shipped at zero is a write-off nobody misses; the same gap recurring on new parts or expired agreements is steady revenue walking out of the door. The threshold that matters is simple: no line worth selling should ship at zero, and that is a rule you can read before dispatch.

The check is already possible with data IFS Cloud exposes. A sales order line carries its unit price and computed value alongside part, quantity, customer, and delivery status. All of it is readable through standard OData projections without writing anything back. Turning that into a watch list is a scheduled read of two things:

1. Priced at zero, not yet shipped: any order line with a zero or empty unit price that is still open, so it can be corrected before the goods leave, ranked by quantity and part so the material ones surface first.
2. Shipped at zero, not yet invoiced: lines that already left carrying no price, the ones to catch before an invoice for nothing is raised.

This is the same read-and-flag discipline that catches a delivered but not invoiced order: the facts are already in the system, they just need something to read the price on the line and raise the ones that would bill the customer nothing.

A sharp order-desk clerk spots a missing price when they happen to look at the line. The problem is that a zero-priced line looks complete: it has a part and a quantity, it does not error, and it flows. Nothing draws the eye to a price field that is simply blank, and habit does not surface a value that is quietly zero.

Because it is a read-only monitoring pattern, it never writes back to IFS Cloud. It surfaces the lines that would ship or bill at zero and leaves the price fix, the pricing decision, or the customer conversation with the person who owns the account.

• Start before dispatch: the highest-value list is open lines still correctable, so the price is fixed before the goods leave.
• Dry-run a full period: log what would have been flagged before a single alert reaches the order desk.
• Separate legitimate zeros: free samples and genuine no-charge lines exist, so allow a marked reason and flag only the unexplained ones.
• No upgrade footprint: standard OData reads only, so an R1/R2 release leaves it untouched and nothing new lives inside IFS Cloud.

See the SCM Automation Pack Book a 30-minute fit call

Dariusz Myśliwiec: 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: Betafence (PRÆSIDIAD) · Newag · RADPOL · Fugro · NGK Ceramics · ATLAS.

IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.

Because the expensive part of an IFS Cloud upgrade is not the upgrade itself. It is discovering, in the new version, what you should have found beforehand. The IFS Cloud upgrade tax is paid almost entirely in things that were knowable in advance: an extension nobody realised reached into modified core, a report built on a view that changed, an integration wired to an interface IFS never promised to keep.

A checklist converts that risk into a to-do list. Each point below is something you can inspect, decide on and sign off before the release is booked, while you still have time and before the deadline forces rushed decisions.

1. Inventory every extension. Build one list of all customisations, reports, integrations, custom events, workflows and modifications, including the orphans nobody owns. You cannot assess what you cannot see.
2. Classify each one by risk. Rate every item Safe, Refactor, Rewrite or Retire, based on whether it lives inside the Extensibility Framework or reaches outside it. This single step tells you where the upgrade tax will land.
3. Check your custom events and workflows. Confirm each event still binds to a supported entity and that its logic uses standard interfaces. Events that reach into internal packages are the ones that fail quietly after a release.
4. Review Quick Reports on volatile views. Reports built on database views that IFS may restructure are a classic silent break. Flag any Quick Report or SQL report reading from non-guaranteed views and plan to re-point or re-test them.
5. Assess RBAC and Segregation of Duties exposure. A new release can add, rename or reshape permission sets and projections. Confirm your role model and SoD rules still hold, so the upgrade does not quietly widen access.
6. Verify integration and OData contracts. List every inbound and outbound interface and confirm each uses a supported OData/REST projection, not an internal API. Check field mappings against the target version before, not after.
7. Confirm test-environment parity. Your test environment must mirror production: same configuration, same data shape, same integrations connected. A dry run against a stale copy proves nothing.
8. Write a rollback plan. Decide, in advance and in writing, how you revert if the upgrade fails validation: backup points, cut-over window and the exact trigger that says “stop and roll back”.
9. Get executive sign-off. One named owner accepts the plan, the risk classification and the go/no-go criteria. Readiness without accountability is a wish, not a plan.
10. Lock a realistic timeline. Sequence inventory, remediation, dry run, re-test and go-live with slack built in. A timeline that assumes nothing breaks is the one most likely to slip.

Work these ten points in order and the pattern is clear: the first two find the risk, the middle six remove it, the last two make sure someone owns the outcome.

The same three points catch most teams, every release. Knowing them in advance is half the battle.

RBAC drift is the quietest of the three, because it throws no error. Access simply widens. If your SoD model matters for audit or compliance, treat the upgrade as a moment to re-prove it. The mechanics are covered in Permission Sets and Segregation of Duties in IFS Cloud.

A checklist you run once is useful. A checklist you never need to run is better. The durable fix is to stop generating upgrade risk in the first place: keep every extension inside the supported framework so there is nothing on the far side of the line to break.

• Build automation with Custom Events and Workflows, never modified core
• Read reports from supported, stable projections rather than volatile views
• Wire integrations to versioned OData/REST, not internal APIs
• Enforce access through RBAC and SoD, reviewed each release

That is the Clean Core discipline: the same one behind IFS Cloud Clean Core. Apply it to everything you build and the checklist shrinks to a re-validation, release after release.

Get an Update-Safe Audit Book a 30-minute call

Dariusz Myśliwiec: 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 through an independent practice. You talk to the consultant who does the work, not a sales layer.

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.