Uw SBR-jaarrekening is afgekeurd. Welke regel is het?
De melding komt uit de validatie, niet uit een inhoudelijk oordeel. Zoek de code op, herstel de oorzaak in de bron en valideer opnieuw.
Kort antwoord
Een afgekeurde SBR-deponering komt bijna altijd terug op één regelcode. De FR-NL-regels toetsen de mechanica van het bestand: tekenset, schemaRef, contexten, decimalen en voetnoten. De NL-KVK-regels toetsen daarbovenop wat het handelsregister zelf verlangt. Controleer eerst het entry point, dan de namespace van elk concept, en pas daarna de losse code.
Werk van grof naar fijn
De verleiding is om de eerste code op te zoeken en die te repareren. Dat kost vaak de meeste tijd, want een verkeerd entry point produceert een reeks codes die tegelijk verdwijnen zodra het entry point klopt.
Houd daarom deze volgorde aan.
- Past het entry point bij de bedrijfsklasse en de sector? Banken, verzekeraars en woningcorporaties hebben eigen entry points.
- Staat elk concept in de juiste namespace? bw2-titel9:, rj:, kvk: en ww: zijn aanvullend en nooit uitwisselbaar.
- Pas daarna: de individuele regelcodes, van boven naar beneden in de validatie-uitvoer.
Twee regelfamilies, twee soorten fouten
De SBR Filing Rules en Guidelines, de codes FR-NL en FG-NL, gaan over de mechanica van het bestand: welke tekens zijn toegestaan, waar de schemaRef staat, hoe een context eruitziet, of afronding met decimals of met precision wordt uitgedrukt en of voetnoten mogen voorkomen.
De NL-KVK-businessrules komen daar bovenop en toetsen wat het handelsregister van de inhoud van de aanlevering verlangt. Een pakket kan dus foutloos zijn volgens de ene familie en toch afketsen op de andere.
Herstel in de bron, niet in het bestand
De xHTML met de hand aanpassen werkt precies één keer. Het pakket wordt gegenereerd, dus de volgende generatie overschrijft uw ingreep, en een handmatige reparatie schendt regelmatig een andere regel: een tweede schemaRef verwijderen kan de verwijzing naar de taxonomie kapotmaken die u nodig had.
Herstel daarom bovenstrooms. Vervang het teken in de bron, kies het andere concept, haal het dubbel getagde bedrag weg en genereer opnieuw. Dan is de volgende deponering ook goed.
Waar de meeste afkeuringen vandaan komen
Vier oorzaken verklaren het merendeel. Tekstherkenning die typografische aanhalingstekens, opsommingstekens of andere tekens buiten de toegestane bereiken achterlaat. Een meegeleverd accountantsverslag dat zijn eigen schemaRef meebrengt, waardoor het pakket er twee heeft. Hetzelfde bedrag dat zowel in een samenvatting als in het overzicht is getagd. En een exporteur die een tijdstempel in een datumcontext schrijft.
Veelvoorkomende FR-NL-regels en wat ze eisen
Deze regels toetsen het bestand. Zoek de code op in de validatie-uitvoer en lees hier wat er in de bron moet veranderen.
| Code | Wat de regel eist | Wat er in de praktijk misgaat |
|---|---|---|
| FR-NL-1.01 | Geen byte order mark aan het begin van het bestand | Een editor die het bestand als UTF-8 met BOM wegschrijft |
| FR-NL-1.02 | Alleen tekens uit de toegestane Unicode-bereiken | Typografische aanhalingstekens, opsommingstekens, emoji of CJK-tekens uit tekstherkenning |
| FR-NL-1.05 | Geldige UTF-8-codering | Een bron die als Latin-1 of Windows-1252 is opgeslagen |
| FR-NL-2.03 | xml:lang op het root-element html | Een sjabloon dat de taal alleen in de metadata zet |
| FR-NL-2.04 | Precies één link:schemaRef | Een meegeleverd accountantsverslag dat zijn eigen schemaRef meebrengt |
| FR-NL-2.05 | Geen link:linkbaseRef | Losse linkbases die naast de taxonomie worden meegestuurd |
| FR-NL-3.01 | Datumcontexten zonder tijd, dus JJJJ-MM-DD | Een exporteur die er een tijdstempel achter zet |
| FR-NL-3.04 | Geen xbrli:forever | Een context zonder einddatum voor een gegeven dat wel een periode heeft |
| FR-NL-5.01 | Geen dubbele feiten met hetzelfde concept, dezelfde context en dezelfde waarde | Een totaal dat zowel in de samenvatting als in het overzicht is getagd |
| FR-NL-5.06 | decimals in plaats van precision op numerieke feiten | Een generator die de oudere schrijfwijze aanhoudt |
| FR-NL-5.07 | Geen xsi:nil op feiten | Een lege regel die als nihil wordt getagd in plaats van weggelaten |
| FR-NL-6.01 | Geen voetnoten, dus geen link:footnote of ix:footnote | Een toelichtende noot die als XBRL-voetnoot wordt gekoppeld in plaats van als tekst |
Een pakket dat al deze regels doorstaat, kan inhoudelijk nog steeds verkeerd getagd zijn. Voor dat oordeel kijkt u naar de gekozen concepten en naar de calculatierelaties, die onder Calculations 1.1 uit de taxonomie zelf komen.
Vragen die hierbij horen
Ik hoor alleen dat de aanlevering is afgekeurd. Waar vind ik de code?
In de validatie-uitvoer van de software die het pakket heeft gemaakt. Heeft u die niet, laat het pakket dan door een validator lopen die de regel benoemt en zegt wat eraan moet gebeuren, in plaats van alleen een code terug te geven.
Mag ik de xHTML met de hand aanpassen?
Het kan, maar het lost zelden iets duurzaam op. Het pakket wordt gegenereerd, dus de volgende generatie overschrijft de ingreep, en handmatige reparaties schenden vaak een andere regel.
Wat is het verschil tussen een waarschuwing en een fout?
Alleen fouten blokkeren. Waarschuwingen wijzen op iets dat opvalt maar de aanlevering niet tegenhoudt. Behandel ze wel als leesvoer: ze staan er meestal omdat iets net anders is dan gebruikelijk.
Wij krijgen een calculatiefout, geen FR-NL-code.
Dan sluiten de optellingen niet aan volgens de calculatierelaties uit de taxonomie. Kijk eerst naar de namespaces: een concept uit de verkeerde namespace zit niet in de calculatieboom waarin u het verwacht, en dan klopt de som per definitie niet.
Waarom faalt hetzelfde bedrag als duplicaat?
FR-NL-5.01 verbiedt twee feiten met hetzelfde concept, dezelfde context en dezelfde waarde. Dat gebeurt vooral bij een totaal dat op twee plekken in het rapport staat en op beide plekken is getagd. Tag het één keer.
Kan ik vooraf valideren, voordat ik weer deponeer?
Ja, en dat is het hele punt van een gescheiden validatiestap. Draai het pakket door de validator en lees het daarna in de gratis reader terug, zodat u ziet welk feit bij welke regel in het rapport hoort.
Blijft de aanlevering afketsen?
Laat zien welke code u terugkrijgt, dan kijken we samen naar de oorzaak in de bron.