Lesson 5 — Mandatory-field rules, and the error you should be glad to see
This is the lesson that turns a frightening upgrade morning into a Tuesday.
The obligation. Before a document is sent it is checked against the MoF Data Dictionary. That is not a courtesy your software performs; it is the standard the access point applies on the other side. An access point rejects documents rather than filling gaps in them, so every field it needs has to be present before the document leaves.
The mental model. Most of these checks are built in. The ones covering addresses, countries and line descriptions ship as editable rule records you can read on screen — and because they are records rather than code, you can archive one to stop it checking, or add a company-specific rule of your own. Those three areas are on screen precisely because they are the three that most often need per-company handling.
The click path. Accounting → Configuration → UAE E-Invoicing → Mandatory-Field Rules. Read the list once before you go live; it takes a few minutes and it tells you exactly what will be checked.
| What the shipped rules cover | Where that data lives | The usual cause of a failure |
|---|---|---|
| Addresses | Your company record and the customer contact | A contact created years ago with a name, a phone number and nothing else |
| Countries | Your company record and the customer contact | An imported contact whose country was never mapped |
| Line descriptions | The invoice line itself | A line carrying a bare product code, or a description left blank on a manually added line |
One message, one place to look. A failing rule reports through the same Send & Print message as every other validation error. There is no separate log, no second screen and no technical queue to go hunting in. That matters more than it sounds: a validation system with two places to look is a validation system where one of them goes unread.
You may archive a rule, and you should think before you do. Archiving stops a rule checking, and there are legitimate reasons to do it — a rule that duplicates a stricter check of your own, for instance. What archiving does not do is change what happens at the access point. The specification is not enforced by your rule list; your rule list is a local early warning of it. Archive a rule because it is failing and you have removed the warning while keeping the defect, and you will meet the same problem later as a rejection you cannot argue with.
The post-upgrade missing address is the feature working as intended. If invoices that have gone out happily for years suddenly report a missing address, nothing has broken. The address is mandatory under the MoF specification, and the access point would have rejected the document anyway. Fill in the company and customer address and the error clears. Meeting that error inside your own system, in your own time, is cheap; meeting it as a rejection after go-live is not.
The worked example. Marina Ridge exports its customer list in August, before anything is live. Of 412 active customers, 63 have no street line and 9 have no country at all. The 63 are the visible problem and the easy one: each would fail the address rule and report through the Send & Print message. The 9 are the dangerous ones, because a contact with no country does not resolve to the PINT AE format, so those invoices fall silently out of scope instead of failing loudly. One afternoon of data work in August removes both.
The failure mode. The mistake to avoid is treating the rule list as the specification. It is not. Most of the checks are built in and never appear on that screen, so a rule list you have read end to end is not a guarantee that nothing else is checked. Read the rules to understand what is being checked locally and to add what your company needs — not to discover the whole of the MoF Data Dictionary, which lives with the Peppol PINT AE specifications and is course 3.1's subject.