Every currency amount in S/4 carries an assumption most people never have to think about: two decimal places. Ringgit, euro, dollar, all round comfortably to cents and nobody questions it. Then a GCC entity posts in Kuwaiti Dinar, which runs three decimal places, and an app that sailed through UAT for six months starts producing numbers that are off by a factor of ten.
This happened on a GL mass creation Fiori app I worked on. UAT used MYR and SGD test data the whole way through, both two decimal currencies, and every test case passed. Three weeks after go-live, someone posted a batch in KWD and the amounts that landed in the GL were a tenth of what the user had typed into the screen. Not random, not occasional, consistently a factor of ten low. That consistency is what made it findable: a bug that's always wrong by exactly 10x is a decimal place problem, not a logic problem.
Where the assumption actually lives
SAP stores currency amounts internally with a fixed five decimal places regardless of the currency, and converts to the currency's actual decimal precision at the application layer using table TCURX. Most currencies aren't in TCURX at all, which means the system defaults to two decimals for them. KWD, BHD, OMR, and a handful of others are in there with a CURRDEC value of 3, and JPY shows up with 0. If your code path does the conversion itself instead of asking the system to do it, and it was written assuming two decimals because that's what every test currency used, you'll get a clean compile and a wrong number.
The specific bug in that app was a custom conversion routine that took the raw five decimal internal value and divided by 10**2 unconditionally to get the display value, instead of looking up the actual decimal count for the currency in play and dividing by 10 raised to that. For KWD, dividing a three decimal amount by 100 instead of 1000 gives you exactly a tenth of the correct figure.
DATA: gt_curr_dec3 TYPE STANDARD TABLE OF tcurx,
lv_decimals TYPE tcurx-currdec.
SELECT * FROM tcurx INTO TABLE gt_curr_dec3.
READ TABLE gt_curr_dec3 INTO DATA(ls_curr) WITH KEY currkey = iv_currency.
IF sy-subrc = 0.
lv_decimals = ls_curr-currdec.
ELSE.
lv_decimals = 2.
ENDIF.
lv_display_amount = iv_internal_amount / ( 10 ** lv_decimals ).
That's the whole fix. The hard part wasn't writing it, it was finding where the hardcoded assumption was hiding, because nothing about the code looked wrong on a read through if you didn't already know KWD existed.
The OData layer has the same blind spot
If you're exposing the amount through a CDS view with @Semantics.amount.currencyCode, the Fiori Elements layer will generally respect the currency specific decimal precision automatically once the annotation is wired up correctly, which is the right reason to use the standard semantics annotations instead of plain Edm.Decimal with a hardcoded Scale. But that only protects you on the read side. Anything doing manual currency math in a custom action handler, a validation, or a determination still needs to ask TCURX, not assume.
Why this kind of bug survives testing
Two decimal currencies are the overwhelming majority of test data anyone writes by default, because they're the ones the test author actually uses day to day. Nobody writes a KWD test case unless they've been burned by one before, or the requirements document specifically calls out a GCC rollout. If your org has even one entity transacting in a three decimal currency, it belongs in your regression pack permanently, the same way you'd keep a negative amount test case or a cross fiscal year posting test case. It's cheap insurance against a bug that's invisible until exactly the wrong currency shows up in production.