Two people sit in front of the same screen at an acceptance meeting. The consultant points at a field and says this was always standard. The key user shakes her head and says no; we asked for this in the workshop, it was built for us. Both of them are calm. Both of them are certain. Neither of them is lying.
That is the strange part. Nobody in the room is wrong. They are just reading from two different dictionaries.
Nobody in the room is wrong. They are just reading from two different dictionaries.
A false friend
In languages there is a thing called a false friend: two words that look identical across languages but carry different meanings. A speaker trusts the word, uses it the way it works at home, and walks straight into a misunderstanding. The word did the betraying, not the person.
Standard is a false friend inside an IFS Cloud project. The client and the vendor both use it constantly. They nod when the other says it. They write it into workshop notes and status reports. And the whole time it means two different things.
In the client’s dictionary
Anything a modern ERP should obviously do. If a competitor has it, if it feels basic, if a salesperson once showed it in a demo, it is standard. Standard means included. Standard means already paid for.
In the consultant’s dictionary
Shipped in the product, configurable without custom code, upgradeable without extra hands at the next release. Everything else is a change, and a change has a number, a cost, and a line on an invoice.
Same word. Two dictionaries. The gap between them is where projects quietly bleed.
The real invoiceWho actually pays
The usual question is who pays for the confusion, and the usual answer is the client through change requests, or the vendor through eroded margin. That framing is too small. It only counts money, and it only counts the people who signed.
Walk forward two years. The consultant who drew the line has rolled off to another project. The sponsor who approved the budget has changed jobs. The salesperson is long gone. The custom event action they argued about is still running every night against ORDER_QUOTATION, and nobody in the building remembers why it exists or whether it is safe to touch.
The maintenance developer
Inherits a custom package with no comment explaining the intent, and has to decide, alone, whether it is safe to touch.
The key user
Stops trusting the system because it does one thing here and a different thing there, for reasons nobody can name.
The next partner
Quotes high on everything, because they cannot tell which layer is product and which layer is somebody’s old promise.
The invoice was the cheap part. What really got spent was trust, and it was spent by people who never agreed to the deal.
Where the line actually lives in IFS Cloud
The abstraction becomes real the moment you look at objects. The trouble is never the obvious cases: it is the field and the event, the things small enough to wave through and real enough to come back.
| The object | What it really is | Who owns it at the next upgrade |
|---|---|---|
| A workflow set up in the application, a rule maintained on a screen, a value in a basic-data table | ✅ Standard, configuration | Nobody. Upgrades come along for the ride. |
| A custom field | 🟡 Grey zone, an addition that feels standard | Low effort each, but at volume, real maintenance and documentation weight nobody scoped. |
A custom event with a custom event action |
🔧 Modification, even when it looks small | Someone owns that PL/SQL across every future upgrade, and someone should have said so out loud. |
| A projection extension or a custom entity | 🧩 Custom, and everyone agrees | Clearly the project’s. The easy case; never the one that bites. |
Write the dictionary before you write the contract
The fix is not a longer contract. It is one honest conversation held early, while everyone still likes each other.
Agree what "standard" means: before signing
On this scope, in this version of IFS Cloud. Write down a handful of real examples the client assumes are included. Let the consultant mark each one as configuration, custom field, or custom logic, and say plainly what a change would cost, while the answer is cheap, not at acceptance when it is a fight.
Put the shared dictionary where the work happens
Not in an annex nobody opens, in the room where the work happens. The point is not to win the argument later. The point is to never need to have it.
The line is a translation, not a legal detail
The line between standard and modification is not something to settle at the end. It is a translation done at the start. Skip it, and you do not save the work, you just hand the bill to someone who was not there to say no.
Back in the meeting room
Go back to the two people in front of the screen. They were never really arguing about a field. They were discovering, far too late, that they had been speaking slightly different languages for months and calling it agreement.
The line between standard and modification is not a legal detail to be settled at the end. It is a translation done at the start.
Define "standard" before you sign, not at acceptance
We run the dictionary conversation at the start of an IFS Cloud project, when the answer is still cheap, and we translate scope into configuration, extension, or modification so nobody is surprised two years later.
Book a scoping conversation