Release Date: 17. March 2026
Release Summary
Corrects faulty Modulus‑10 KID calculation for Norwegian SCB Payment IDs (now uses Luhn correctly).
Fixes rejected or missing KIDs on sales invoices.
Aligns thousand/decimal separators with the selected region for consistent formatting.
Bug Fixes
Payment ID
Corrected Modulus‑10 KID calculation in SCB Document Customizer for Norwegian setup
In the Document Customizer, the calculation of the SCB Payment ID (KID) for Norwegian setups using Modulus 10 was incorrect. This caused the control digit on sales invoices to differ from the value expected according to the official KID specification, leading to rejected payments with errors such as “invalid KID” / “requires correct KID”.
With this hotfix, the Modulus 10 logic in Document Customizer has been corrected so that the KID/SCB Payment ID is now calculated according to the KID specification for 16‑character KIDs using the Luhn algorithm. The weight mask used for the Mod10 algorithm has been updated to start from 21 instead of 12, ensuring that the control digit printed on the document matches external Luhn/KID validation (for example, as verified via (SimplyCalc) Luhn algorithm - Calculate check digit and https://www.mastercardpaymentservices.com/norway/utvikler/kid/).
This fix resolves an issue where:
KIDs printed on Document Customizer‑generated documents in the Norwegian production environment were rejected as invalid.
Modulus 11 could not be used as a workaround, because the SCB Payment ID became empty with that setup.
Manual correction of KIDs per invoice was not a realistic option in production.
After installing this version of Document Customizer, existing Norwegian setups using 16 characters with Modulus 10 can continue to be used, and the generated KID on sales invoices will be accepted by the payment processor.
Formatting
Fixed inconsistent thousand and decimal separators on Document Customizer sales documents so all amounts now follow the selected format region.
Previously, sales documents printed with Document Customizer could show different number formats for line amounts and totals when using specific combinations of user language, user region, document language and document region format (for example, English (United States) with da‑DK). In these scenarios, thousand and decimal separators on the totals did not match the separators used on the lines or the selected format region, which could cause confusion when reading amounts and VAT specifications.
This has been corrected by setting the Language property for decimal values according to the chosen Format Region, ensuring a consistent and correct representation of thousand and decimal separators across all amounts on the document (lines, totals, and VAT specification).