Your SBR filing was rejected. Which rule is it?
The message comes from validation, not from a judgment on the accounts. Look up the code, fix the cause at source, and validate again.
Short answer
A rejected SBR filing almost always comes down to one rule code. The FR-NL rules test the mechanics of the file: character set, schemaRef, contexts, decimals and footnotes. The NL-KVK rules test what the trade register itself requires on top. Check the entry point first, then the namespace of every concept, and only then the individual code.
Work coarse to fine
The temptation is to look up the first code and repair that. It usually costs the most time, because a wrong entry point produces a series of codes that all disappear at once as soon as the entry point is right.
So keep this order.
- Does the entry point match the size class and the sector? Banks, insurers and housing associations have their own.
- Is every concept in the right namespace? bw2-titel9:, rj:, kvk: and ww: are complementary and never interchangeable.
- Only then: the individual rule codes, top to bottom in the validation output.
Two rule families, two kinds of error
The SBR Filing Rules and Guidelines, the FR-NL and FG-NL codes, govern the mechanics of the file: which characters are allowed, where the schemaRef sits, what a context may look like, whether rounding is expressed with decimals or precision, and whether footnotes may appear at all.
The NL-KVK business rules sit on top and test what the trade register requires of the submission. A package can therefore be clean under one family and still bounce on the other.
Fix it at source, not in the file
Hand-editing the xHTML works exactly once. The package is generated, so the next generation overwrites your edit, and a manual repair regularly breaks another rule: removing a second schemaRef can take out the taxonomy reference you needed.
Repair upstream instead. Replace the character in the source, choose the other concept, remove the double-tagged amount, and generate again. Then the next filing is right too.
Where most rejections come from
Four causes account for the bulk. Text recognition leaving typographic quotation marks, bullet glyphs or other characters outside the permitted ranges. An auditor's report attached with its own schemaRef, leaving the package with two. The same amount tagged both in a summary and in the statement. And an exporter writing a timestamp into a date context.
Common FR-NL rules and what they require
These rules test the file. Find the code in the validation output and read here what has to change in the source.
| Code | What the rule requires | What goes wrong in practice |
|---|---|---|
| FR-NL-1.01 | No byte order mark at the start of the file | An editor writing the file as UTF-8 with BOM |
| FR-NL-1.02 | Only characters from the permitted Unicode ranges | Typographic quotation marks, bullet glyphs, emoji or CJK characters from text recognition |
| FR-NL-1.05 | Valid UTF-8 encoding | A source saved as Latin-1 or Windows-1252 |
| FR-NL-2.03 | xml:lang on the root html element | A template that records the language only in the metadata |
| FR-NL-2.04 | Exactly one link:schemaRef | An attached auditor's report bringing its own schemaRef |
| FR-NL-2.05 | No link:linkbaseRef | Loose linkbases shipped alongside the taxonomy |
| FR-NL-3.01 | Date contexts without a time, so YYYY-MM-DD | An exporter appending a timestamp |
| FR-NL-3.04 | No xbrli:forever | A context left open-ended for a value that does have a period |
| FR-NL-5.01 | No duplicate facts with the same concept, context and value | A total tagged both in the summary and in the statement |
| FR-NL-5.06 | decimals instead of precision on numeric facts | A generator keeping to the older spelling |
| FR-NL-5.07 | No xsi:nil on facts | An empty line tagged as nil instead of left out |
| FR-NL-6.01 | No footnotes, so no link:footnote or ix:footnote | An explanatory note attached as an XBRL footnote instead of as text |
A package that passes all of these can still be tagged wrongly. For that judgment you look at the concepts chosen and at the calculation relationships, which under Calculations 1.1 come from the taxonomy itself.
Questions that come with this
All I hear is that the submission was rejected. Where is the code?
In the validation output of the software that built the package. If you do not have it, run the package through a validator that names the rule and says what to do about it, rather than returning a code alone.
May I edit the xHTML by hand?
You can, but it rarely fixes anything durably. The package is generated, so the next generation overwrites the edit, and manual repairs often break another rule.
What is the difference between a warning and an error?
Only errors block. Warnings flag something notable that does not stop the submission. Read them anyway: they are usually there because something is slightly unlike the norm.
We get a calculation error, not an FR-NL code.
Then the totals do not add up under the calculation relationships from the taxonomy. Look at the namespaces first: a concept from the wrong namespace is not in the calculation tree you expect it in, so the sum cannot balance.
Why does the same amount fail as a duplicate?
FR-NL-5.01 forbids two facts with the same concept, context and value. It happens most with a total that appears in two places in the report and is tagged in both. Tag it once.
Can I validate before filing again?
Yes, and that is the point of a separate validation step. Run the package through the validator, then read it back in the free reader so you can see which fact belongs to which line in the report.
Still bouncing?
Show us the code you get back and we will look at the cause at source with you.