Softwarepakketten.nl
BCS HR Software
EXACT Software
VISMA E-accounting
E-boekhouden

Begrippen > RGS

Referentie Grootboekschema (RGS) is het beoogde standaard grootboekschema in Nederland.

Site index over [ RGS ]
RGS
RGS Ready
Onderzoek en artikelen op deze website over [ RGS ]
Complete RGS gids: ontstaan, invloed SBR en RGS MKB (11-04-2023)
Dit rapport richt zich primair op de implementatie van RGS binnen de doelgroep MKB ondernemers en de daar ondersteunende accountants- en administratiekantoren. Daarnaast richt dit rapport zich op de historie en oorspronkelijke doelstelling van RGS. De opbouw van het RGS en de invloed van het SBR programma.
RGS succesfactoren en valkuilen: is het na 10 jaar tijd voor een RGS-feestje? (17-11-2021)
De markt is volgens mij positief gestemd over een ontwikkeling als het Referentie Grootboekschema (RGS), maar ook erg terughoudend over het in gebruik nemen van het huidige RGS. Bij leveranciers van boekhoudsoftware is RGS ook niet onopgemerkt gebleven. 15 softwareleveranciers zijn RGS-ready en dat aantal lijkt alleen maar toe te nemen. Leveranciers van fiscale aangiftesoftware gebruiken RGS voor het automatisch inlezen van cijfers voor de winstaangifte IB en VPB.
Onderzoek naar de synergie tussen het Referentie GrootboekSchema en elektronisch factureren (11-04-2021)
Onderzoek in opdracht van het ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK) in hoeverre e-factureren en RGS elkaar kunnen versterken. Samengevat onder de noemer “Synergie RGS en e-facturatie”.
Terugblik kennisevent 2019 met: PSD2, Contracten cloud/saas, AVG-proof, UBL, RGS en APIs (10-10-2019)
Op woensdag 9 oktober 2019 organiseerde Onderzoeksbureau GBNED het 2e "Kennisevent administratieve software" te Hoevelaken. Met aandacht voor PSD2 in relatie tot administratieve software, contracten voor Saas/cloud, AVG-proof zijn, RGS Ready, Elektronisch factureren: UBL in relatie tot de Europee standaard EN16931 en API's.
Presentaties Seminar Robotic accounting 17-4-2019 beschikbaar (18-04-2019)
Op woensdag 17 april 2019 heeft voor de derde maal het "Seminar Robotic accounting" plaatsgevonden te Hoevelaken. Met presentaties over Robotic accounting, Robotic Process Automation (RPA) en gerelateerde ontwikkelingen, zoals: Gids boekhoudsoftware 2019, RGS Ready, No hands accounting, Robotic Revenue Validation, Toekomst accountancybranche en out-of-the-box denken, Elektronisch factureren met standaards als UBL en PEPPOL. Met tot slot Elektronisch factureren LIVE getoond.
Waarom is het ReferentieGrootboekschema (RGS) na 6 jaar nog niet van de grond gekomen: wij zochten het voor u uit (31-08-2018)
Het initiatief voor het Referentie grootboekschema (RGS) is eind 2011 ontstaan. Het eerste werkdocument Referentie Grootboekschema dateert van 18 mei 2012. Inmiddels (zomer 2018) is RGS versie 3.0 alweer een tijdje een feit. Het gebruik van RGS in de praktijk lijkt na 6 jaar echter nauwelijks van de grond gekomen. De hamvraag is "wat gaat er mis met de introductie van RGS?"
Presentaties kennisevent administratieve software: Privacy, Instant payments, UBL EN16931, PEPPOL, Blockchain, RGS en PSD2 (30-06-2018)
Terugblik met presentaties van Kennisevent administratieve software (gehouden op 27 juni 2018) met betrekking tot en gerelateerd aan standaard administratieve software. Met ontwikkelingen als RGS, PSD2, Instant Payments, UBL, PEPPOL en API's. En de Gids boekhoudsoftware 2018 met Nulmeting blockchain en boekhoudsoftware.
Terugblik en presentatie praktijkdag digitaal dossierbeheer en data-analyse in het teken van RGS (14-3-2018) (15-03-2018)
Op woensdag 14 maart 2018 heeft voor het 7e jaar op rij de ICT Accountancy praktijkdag "Digitaal dossierbeheer en data-analyse" plaatsgevonden te Hoevelaken. Deze dag stond ditmaal voor een belangrijk deel in het teken van RGS (Referentie Grootboekschema) met meerdere ervaren sprekers op dit gebied. Presentatie zijn beschikbaar.
Presentaties ICT Accountancy Jaarcongres 2-11-2016 beschikbaar met o.a. Cybersecurity, Self service BI, SBR, RGS, UBL, CRM en HRM (03-11-2016)
Op woensdag 2 november 2016 vond in EXPO Hoevelaken voor de 15e maal het ICT Accountancy Jaarcongres plaats met ruim 200 deelnemers en 30 exposanten op de informatiemarkt. Een initiatief van Onderzoeksbureau GBNED in samenwerking met NOVAK. Actuele onderwerpen als Cybersecurity, Self service BI, SBR, RGS, Elektronisch factureren met UBL, CRM, HRM en meldplicht datalekken passeerden de revue.
Terugblik en presentaties praktijkdag RGS en SBR op 20 april 2016 (21-04-2016)
Op 20 april 2016 vond de "Praktijkdag RGS en SBR" plaats met aandacht voor het elektronisch deponeren van de jaarrekening, SBR en banken kredietrapportage, SBR in de accountantspraktijk, uitvragen van CBS via SBR, RGS en SBR in de administratiepraktijk, SBR assurance, het nieuwe rapport "Software voor externe verslaggeving" en tot slot RGS Ready en boekhoudsoftware.
Blogs op deze website over [ RGS ]
Veel meer inzicht vanuit je boekhouding door RGS MKB boekingsdimensies (22-02-2024)
Heb je als ondernemer continu (dus niet alleen na afloop van een boekjaar) inzicht in de kosten per vervoermiddel op kenteken. Inzicht in de opbrengst van afstandsverkopen per EU-land en BTW-code. Een specificatie van privé opname en -stortingen per vennoot. Werkkosten in relatie tot de vrije ruimte. Omzet per productgroep. En inzicht in de kosten per soort van energieverbruik.
De Belastingdienst en openstaande zaken RGS en Auditfile Financieel: voorstel voor afronden (29-08-2023)
De Belastingdienst was in 2012 een van de belangrijke organisaties bij het opstellen van de uitgangspunten rondom het tot stand komen van RGS. Het realiseren van die uitgangspunten bleek echter een brug te ver. Met als gevolg de nodige openstaande zaken ruim 10 jaar na dato. Ook de verdere ontwikkeling van de Auditfile Financieel (XAF) verdient al jaren opnieuw aandacht.
RGS onderbrengen bij het SBR programma en de NBA is verkeerd uitgepakt (10-12-2022)
Inmiddels zijn we 10 jaar bezig met RGS zonder dat het echt tot bloei is gekomen. Nog geen 5% van alle accountants- en administratiekantoren maakt nu optimaal gebruik van RGS. Gebruik je RGS uitsluitend voor de koppeling tussen grootboek en raportagesoftware voor de jaarrekening, dan is de kans groot dat je tevreden bent over RGS. Besef je dan wel dat je minder dan 10% van het RGS potentieel gebruikt.
RGS MKB: decimaal rekeningschema in de maak t/m RGS niveau 4 (29-11-2022)
Met de ontwikkeling van RGS MKB heb ik me even laten verleiden om RGS niveau 5 (mutaties) toe te passen op een aantal plaatsen. Zo ontbreekt op niveau 4 van RGS (grootboekrekeningen) bijvoorbeeld de rekening Vraagposten. En zijn er geen aparte rekeningen voor Gas, Water en Elektra (wie wil dat nu niet apart zien, zeker in deze periode). En wie werkt met de rekening "Afgedragen omzetbelasting" heeft ook pech.
30 kengetallen beschikbaar op basis van RGS met formules voor iedere boekhouding (31-10-2022)
Hoe kun je de accountancysector en financials in het bedrijfsleven stimuleren gebruik te maken van het referentie grootboekschema (RGS). Het antwoord is simpel: "Zorgen dat RGS van toegevoegde waarde is voor de beoogde doelgroep". Inmiddels wordt door GBNED gewerkt aan meerdere initiatieven om het gebruik van RGS in de praktijk te stimuleren. Een van deze initiatieven is RGS kengetallen.
Nooit meer vaste activa en afschrijvingen handmatig overnemen in rapportage- en fiscale aangiftesoftware (31-08-2022)
Als het gaat om registratie van vaste activa worden gegevens als aanschafdatum, restwaarde en WOZ-waarde nu nog massaal met de hand overgenomen in bijvoorbeeld fiscale aangiftesoftware, terwijl dit eenvoudig automatisch is te regelen vanuit de boekhouding. De RGS vaste activastaat is een nieuwe standaard om vanuit de boekhouding vaste activagegevens aan te leveren aan andere systemen, mede op basis van RGS.
Loonjournaalpost automatisch boeken: standaard voor alle salaris- en boekhoudsoftware (21-06-2022)
Je kent het wel: de periodieke loonjournaalpost die maandelijks trouw handmatig wordt ingevoerd in de boekhouding voor zowel kleine als grote bedrijven. Afgezien van salariscorrecties in elk geval 12 maal per jaar handmatig werk voor een administratief medewerker. Dat laatste is verleden tijd met de nieuwe RGS Journaalsoorten.
Overheid en grote ondernemingen laten het MKB onvoldoende meeprofiteren van elektronisch factureren (08-04-2022)
Er zijn overheden en ondernemingen die leveranciers verplichten om facturen via Peppol aan te leveren, maar dat op hun beurt zelf niet doen. Deze partijen blijven gewoon Facturen per email verzenden als bijlage in PDF of in het ergste geval facturen sturen per post.
Vaste activa specificatie automatisch aanleveren aan de winstaangifte, kredietrapportage en jaarrekening (22-08-2021)
Je levert cijfers voor de winstaangifte (IB, VPB) automatisch aan vanuit het grootboek op basis van de RGS brugstaat met grootboeksaldi (of in Json formaat via een API, or else) en dan blijkt dat je achteraf handmatig gegevens moet aanvullen die notabene al wel aanwezig zijn in je boekhouding. Denk aan datum in gebruik name, datum buiten gebruik stelling, WOZ-waarde en de restwaarde. Zaken die niet in je grootboek zitten, maar natuurlijk wel in je vaste activa administratie.
Lastenvermindering en RGS, dankzij het CBS (23-04-2021)
Het Centraal Bureau voor de Statistiek (CBS) toont als eerste grote overheidsorganisatie aan dat een financiële rapportage direct en eenvoudig gevuld kan worden vanuit de boekhouding op basis van louter RGS.
White papers op deze website over [ RGS ]
Bij Informer is innoveren een continu proces met o.a. RGS en AWA, eFactureren, eRetour en PSD2 (03-05-2022)
Automatisch ingevulde WinstAangifte (AWA) voor ZZP’ers, Retourberichten via Peppol en nieuwe API koppeling gaat nog voorbij PSD2. Met het boekhoudprogramma InformerOnline heb je als accountant of boekhouder toegang tot alle tools om op een moderne manier samen te werken met ondernemers. Verschillende innovaties en robots maken het mogelijk dat je als accountant minder tijd kwijt bent aan het boeken van een administratie en je meer kunt focussen op controle en advies.
Klantspecifieke dashboards maken met de Minox RGS Analyzer (20-11-2020)
De toegevoegde waarde van de accountant zit niet in het voeren van de boekhouding. Boekingen goed in het boekhoudpakket krijgen is een middel – het doel is om inzichten uit de boekhouding te krijgen en daar acties op te ondernemen die waarde toevoegen.
WIKI's over [ RGS ]
Boekhoudpakketten en Analytische boekhouding

Het bijhouden van een (grootboek)administratie en eventueel onderliggende subadministraties, zoals kostenplaatsen, vaste activa, etc., is enerzijds van belang voor een organisatie zelf en anderzijds om te voldoen aan, al dan niet wettelijke, rapportageverplichtingen. De bekendste voorbeelden van deze verplichtingen zijn de jaarrekening t.b.v. publiceren bij de Kamer van koophandel en de winstaangifte t.b.v. de aangifte-IB of -VPB. Daarnaast kennen we bijvoorbeeld de kredietrapportage aan een bank of andere kredietverstrekkers.

Het ligt dan ook voor de hand om met een rekeningschema te werken dat zoveel mogelijk gebaseerd is op betreffende verplichtingen. Zodat rapportages (al dan niet via aparte rapportage- of fiscale aangiftesoftware) eenvoudig uit de boekhouding afgeleid kunnen worden. En er dus niet allerlei herberekeningen hoeven plaats te vinden via de boekhoudsoftware of extracomptabel (voor zover dat achteraf uberhaupt mogelijk is).

BTW-aangifte, ICP-opgave en boekhoudsoftware

Functionaliteit voor BTW-aangifte is standaard aanwezig binnen elk boekhoudpakket. Alleen voor het elektronisch indienen van een BTW-aangifte bij de belastingdienst wordt soms gebruik gemaakt van andere software. De eigenschappen die verderop aan de orde komen tonen aan dat er nogal wat regelingen zijn als het gaat om BTW-aangifte. Naast de standaard BTW-aangifte (meestal per kwartaal voor kleine ondernemers en per maand voor grotere ondernemers) kan ook sprake zijn van een ICP-opgave (voor IntraCommunautaire Prestaties van goederen en diensten). Het betreft dan leveringen binnen de Europese Unie. Bij een ICP-opgave is in elk geval sprake van een geldig BTW-nummer van zowel de afzender als de ontvanger. 

Grootboekadministratie en boekhoudsoftware

Het grootboek vormt de basis van een boekhouding en is daarmee voor goede boekhoudsoftware van essentieel belang. Het hart van een grootboek wordt gevormd door een decimaal rekeningschema dat onderverdeeld is van rubriek 0 t/m 9. Om zelf een decimaal rekeningschema op te zetten kan desgewenst gebruik gemaakt worden van RGS (Referentie grootboekschema). Zie ook het WIKI onderdeel deciaal rekeningschema.

De meeste leveranciers van boekhoudsoftware leveren een of meer standaard rekeningschema's mee met hun boekhoudsoftware. En ook acccountants- en administratiekantoren beschikken over het algemeen over een of meer standaard rekeningschema's. Het grootboek bevat ook de totaaltellingen van onderliggende subadministraties, zoals debiteuren en crediteuren, vaste activa (afschrijvingen) en kostenplaatsen. Ook uitgebreide administraties, zoals een projectenadministratie, een groothandelsadministratie, een kassa administratie en een productie administratie sluiten in de regel aan bij het grootboek. Denk aan een totaaltelling onderhanden werk in geval van een projectenadministratie.

Het grootboek en decimaal rekeningschema wordt internationaal ook wel aangeduid als Ledger en Chart of accounts. 

Het decimaal rekeningstelsel

Het (decimale) rekeningschema in Nederland is onderverdeeld in 10 rubrieken (0 t/m 9) die ook weer onderverdeeld kunnen worden in subgroepen. Gericht op de MKB ondernemer wordt over het algemeen gewerkt met een 4-cijferig rekeningschema, waarbij de eerste positie de rubriek aangeeft. De rubrieken 0, 1, 2, 3 en 7 zijn (meestal) balansrekeningen. De overige rubrieken (4, 5, 6, 8 en 9) zijn dan resultatenrekeningen, ook wel winst- verliesrekeningen (W&V) genoemd. De indeling van het rekeningschema is op vrijwillige basis in Nederland. Wel zijn er voorschriften voor de indeling van de balans (en indien van toepassing) en resultaten rekening, zoals te publiceren bij de Kamer van koophandel. En de indeling van de Winstaangifte Inkomstenbelasting (IB-winst) en Vennootschapsbelasting (VPB) is standaard bepaald. 

Koppeling salaris- en HR-systemen naar andere softwareystemen

Naast zelfstandige toepassingen voor enerzijds de salarisadministratie en anderzijds HRM zijn er de afgelopen jaren steeds meer geïntegreerde salaris- en HRM-systemen op de markt gekomen.

Met name gericht op functionaliteiten onder de noemer ‘HRM’ zijn er ook zelfstandige toepassingen op de markt die zich uitsluitend richten op één of enkele HRM-aspecten. Zo zijn er meerdere toepassingen op het gebied van ‘verzuimregistratie’ en op het gebied van ‘functieprofilering en matching’. 

Eveneens gericht op functionaliteiten onder de noemer ‘HRM’ zijn er ook zelfstandige toepassingen op de markt, zoals op het gebied van ‘personeelsplanning’ en ‘urenregistratie’, die meer functionaliteit bieden dan verwacht mag worden van alleen ‘HRM’.

Een voorbeeld van dit laatste is software voor urenregistratie met mogelijkheden als projecten c.q. opdrachten plannen, budgetteren, declareren van uren en kosten op basis van facturen. Software voor urenregistratie kent soms een exportfunctie om de te verlonen uren door te geven aan de salarisadministratie als dat van toepassing is. Het aanbod van software voor urenregistratie is vaak branche afhankelijk. Voorbeelden van dit laatste zijn: projectsoftware voor de bouw, werkorders voor de installatiebranche, tijdschrijven voor de advocatuur en declaratiesoftware voor de accountancy. 

Nadere specificaties Europese norm EN 16931 met Nederlandse NLCIUS

Onder de noemer "EN 16931" is in Europa gewerkt aan het maken van één norm voor elektronisch factureren (met als syntaxen UBL en UN/CEFACT). Er wordt hierbij gesproken over een "kernfactuur". De Europese richtlijn 2014/55/EU schrijft voor dat in ieder geval alle aanbestedende diensten in de EU met deze nieuwe norm en bijbehorende syntaxen moeten werken sinds medio april 2019.

Om te starten eerst voorbeeld van een simpele, maar wel complete, factuur in UBL (NLCIUS)

Voordat de elementen op een UBL Factuur verder worden toegelicht volgt onderstaand eerst een simpel, maar compleet, voorbeeld van een factuur met 1 factuurregel en (dus) 1 BTW-percentage.

Opbouw UBL Factuur, afzender factuur (Accounting SupplierParty)

De gegevens van de afzender van de factuur zijn in UBL ondergebracht onder:
[1..1] <AccountingSupplierParty>
   [1..1[ <party>:

  1. [0..1] EndpointID; Elektronische netwerkadressering (EndpointID) van de leverancier, zoals PEPPOL adressering;
    [1..1] PEPPOL  
    Met verplicht SchemeID volgens ISO 6523 ICD code. Voor KVK code 0106 en voor OIN code 0190.
    Nadere specificaties PEPPOL netwerk binnen een UBL-factuur.

  2. [0..*] PartyIdentification; Identificatie van de verkoper. 
    Met element:
    - [1..1] ID; Met optioneel SchemeID volgens ISO 6523 ICD code.
     
    PEPPOL BIS toelichting:
    Dit element wordt zowel gebruikt voor de identificatie van de verkoper, als voor de unieke bankreferentie-identificatie van de verkoper (toegewezen door de bank van de verkoper). Gebruik voor verkoperidentificatie de ICD-codelijst, gebruik SEPA voor een aan de SEPA bank toegewezen crediteurreferentie. Om ervoor te zorgen dat de koper automatisch een leverancier identificeert, moet deze identificatie van de verkoper, de wettelijke registratienummer van de verkoper (zie punt 6) en/of de btw-identificatie van de verkoper (zie punt 5) aanwezig zijn.

    SchemeID
    Het identificatieschema-ID van de verkoper-ID, bijvoorbeeld 0106 (KVK) of 0190 (OIN). Voor aan de bank toegewezen crediteur-ID MOET de waarde "SEPA" zijn

    NLCIUS toelichting:

    Voor het identificeren van de Leverancier (in de communicatie tussen Leverancier en Afnemer) kunnen verschillende soorten identifiers worden gebruikt. Bijvoorbeeld het GLN, KVK nummer, KVK vestigingsnummer, een sector identifier, of bilateraal afgesproken identifier. Dit veld wordt aanvullend gebruikt op het Registratienummer leverancier (zie punt 6) en het BTW nummer (Zie punt 5). (BT-31).
    Het KVK vestigingsnummer kan niet worden gebruikt voor routing op het PEPPOL netwerk, maar alleen voor het identificeren van partijen.

    UBL Ketentest:
    Bovenstaand wordt in de meeste gevallen het KVK-nummer of OIN-nummer gebruikt (zie punt 6).
    In dat geval dus het zelfde nummer als bij het eerder genoemde EndpointID voor SEPA.
       
  3. [0..*] PartyName; Naam van de afzender.
    [0..1] EU-N
    Met element: 
    - [1..1] Name.

    EU-N:
    EU-N stelt zich op het standpunt dat alleen de registratienaam verplicht is (zie onder punt 6 PartyLegalEntity) en daarom deze naam (PartyName) optioneel is!
    Advies UBL Ketentest: naam altijd opgeven.

  4. [0..1] PostalAddress; Postadres van de afzender.
    [1..1] EU-N 
    Met elementen:
    - [0..1] StreetName; straat.
      [1..1] NLCIUS; verplicht indien leverancier in NL.
    - [0..1] AdditionalStreetName. 
    - [0..1] CityName; woonplaats.
      [1..1] NLCIUS; verplicht indien leverancier in NL.
    - [0..1] PostalZone; postcode.
      [1..1] NLCIUS; verplicht indien leverancier in NL
    - [0..1] CountrySubentity; provincie. Niet gebruikelijk in Nederland.
    - [0..*] AddressLine; een of meer aanvullende adresregels.
      [0..1] EU-N
               [1..1] Line; aanvullende adresregel
    - [1..1] Country; landcode.
               [1..1[ IdentificationCode; bijv. NL.

    PEPPOL BIS
    Er moeten voldoende onderdelen van het adres worden gevuld om aan de wettelijke eisen te voldoen.

    NLCIUS

    Volgens de Belastingdienst moeten adressen zo compleet mogelijk zijn. Vermelding van alleen een postbusnummer is niet voldoende. De factuur wordt niet gebruikt om stamgegevens bij te werken. Het ontvangende systeem zal doorgaans niets doen met adresgegevens.

    Gebruik aanvullende adresgegevens wordt afgeraden.
    Gebruik provincie wordt afgeraden.

    UBL Ketentest
    Oneens dat ontvangende systeem niets doet met adresgegevens.
    1. Kan gebruikt worden om adresgegevens leverancier op te nemen als deze nieuw is.
    2. Kan gebruikt worden als sprake is van een adreswijziging. Advies is dan wijziging vooraf melden en laten autoriseren. 

    Uitgaande facturen; zoveel mogelijk straat inclusief huisnummer.
    Inkomende facturen; straat aanvullen met inhoud huisnummer als dit laatste apart is gevuld (via BuildingNumber - dat bij EU-N niet gebruikt wordt). 
    De reden is dat in vorige UBL versies (zoals SI-UBL 1.2) het huisnummer apart opgegeven moest worden via BuildingNumber.

  5. [0..*] PartyTaxScheme; BTW-gegevens van de afzender;
    [0..2] EU-N
    Met elementen:
    - [0..1[ CompanyID; BTW-nummer afzender.
      [1..1] PEPPOL 
    - [1..1] TaxScheme; aanduiding VAT.
               [1..1] ID; aanduiding altijd "VAT".

    NLCIUS
    Dit veld betreft het BTW nummer van de Leverancier. Indien leverancier BTW plichtig is in Nederland, dan moet dit gegeven opgenomen worden.
       
  6. [0..n] PartyLegalEntity; KvK-gegevens van de afzender 
    [1..1] EU-N
    Met elementen:
    - [0..1] RegistrationName; Registratienaam van de afzender
      [1..1] EU-N
    - [0..1] CompanyID; Met optioneel SchemeID volgens ISO 6523 ICD code. Veelal KvK-nummer van de afzender. 
    - [0..1] CompanyLegalForm; Juridische informatie
               NLCIUS: Juridische informatie (CompanyLegalForm) afgeraden. N.v.t. voor Nederlandse leveranciers.

    In plaats van KvK kan ook sprake zijn van een andere instantie, c.q. nummer-uitgave. Zo kennen we in Nederland OIN (Overheids Identificatie Nummer) voor overheden die geen KvK-nummer hebben. Voor KVK code 0106 en voor OIN code 0190.

    OIN staat voor openbare Organisatie-identificatienummers (ook wel "Overheids indentificatienummers" genoemd). 
    Voor meer informatie en raadplegen van OIN zie de Centrale OIN Raadpleegvoorziening

    LET OP:
    Het KVK-nummer (of ander nummer) wordt vooraf gegaan worden door het "schemeID".  
    Dit schemaID bevat dan de ISO 6523 ICD code.

    NLCIUS:
    Als Nederlandse leverancier dan alleen gebruiken KVK code 0106 of OIN code 0190.
       
  7. [0..1] Contact; Contactgegevens afzender.
    Met elementen: 
    - [0..1] Name; 
    - [0..1] Telephone; 
    - [0..1] ElectronicMail; emailadres.

Opbouw UBL Factuur, algemene factuurgegevens (zoals factuurnummer en -datum)

Een UBL factuur bevat de volgende algemene factuurgegevens:

  1. [1..1] ID (Factuurnummer).
     
  2. [1..1] IssueDate (Factuurdatum); als YYYY-MM-DD. 

  3. [0..1] DueDate (Vervaldatum); als YYYY-MM-DD

    PEPPOL BIS
    In het geval dat het te betalen bedrag positief is, is deze vervaldatum van de betaling of de betalingsvoorwaarde aanwezig.

    NLCIUS

    Aanvullend advies:
    Wordt vaak genegeerd wanneer inkoop-/contractvoorwaarden leidend zijn.
       
  4. [0..1] InvoiceTypeCode (Factuurtype code);
    [1..1] EU-N

    PEPPOL BIS

    Toegestane waardes zijn:
    80: debet note relates to goods or services;
    82: metered services invoice;
    84: deber note related to financial adjustments;
    380: standaard factuur;
    381: creditnota; met apart creditnote schema;
    383, 386, 393, 395, 575, 623, 780.

    81: credit note: relates to goods or services;
    83: credit note: related to financial adjustments;
    381: creditnota; met apart creditnote schema;
    396: Factored creditnote;
    532: Forwarder's creditnote.

    NLCIUS
    Toegestane waardes zijn:
    380: standaard factuur;
    381: creditnota; met apart creditnote schema.
    384: correctie factuur;
    389. self billing factuur.
    Vanuit de UBL Ketentest wordt vooralsnog geadviseerd uitsluitend ‘380’ te gebruiken en geen andere InvoiceTypeCode.

    In sommige andere landen wordt voor creditnota's gebruik gemaakt van de code '381'. Daarvoor geldt een apart XML Credit Note schema.
    Meer over creditnota's...

    UBL Ketentest
    Voor een (commerciële) factuur geldt hiervoor standaard de waarde ‘380’.
    De praktijk leert dat niet alle leveranciers de waarde van ‘380’ hebben opgegeven en soms dit element geheel weg laten (het is per slot van rekening optioneel volgens standaard UBL). In het laatste geval kan kan door de ontvanger uitgegaan worden van ‘380’. 
      
  5. [0..*] Note (Algemene factuurinformatie);
    [0..1] EU-N
       
  6. [0..1] TaxPointDate (Peildatum voor belastingen, BTW peildatum);

    PEPPOL BIS

    Dit element is vereist als de datum voor de BTW-bepaling verschilt van de uitgiftedatum van de factuur. 

    NLCIUS
    (BR-NL-20)
    Ontraden:
    BTW boekingsdatum wordt afgeleid van factuurdatum/leverdatum. Dit element wordt ontraden en als het voorkomt kan het genegeerd worden.

    Advies UBL Ketentest
    In Nederlandse boekhoudsoftware is het gebruikelijk de datum voor de BTW-bepaling af te leiden van de factuurdatum. 
    Geadviseerd wordt deze BTW boekingsdatum niet te gebruiken.
       
  7. [0..1] DocumentCurrencyCode (Valutacode voor de gehele factuur);
    [1..1] EU-N
    Vanuit Nederland in verreweg de meeste gevallen "EUR". 
       
  8. [0..1] TaxCurrencyCode;  
    Aanvullend op de hiervoor genoemde valutacode (DocumentCurrencyCode) kan een afwijkende, valutacode worden opgegeven voor voor belastingen.

    PEPPOL BIS

    De valuta die wordt gebruikt voor btw-boekhouding en rapportagedoeleinden, zoals geaccepteerd of vereist in het land van de verkoper. Wordt gebruikt in combinatie met het totale btw-bedrag van de factuur in de valuta voor boekhouding, wanneer de valutacode voor de btw-boekhouding verschilt van de valutacode van de factuur.
    Deze valutacode moet dan afwijken van de hiervoor genoemde DocumentCurrencyCode.

    NLCIUS
    (BR-NL-19)
    Ontraden. Dus niet opnemen.

    Advies UBL Ketentest
    Niet opnemen.
        
  9. [0..1] AccountingCost; referentie van de klant

    NLCIUS
     
    Toelichting: 
    Referentienummer uit het referentiegrootboekschema, tenzij de afnemer een ander grootboekrekeningnummer heeft doorgegeven aan de leverancier. Alleen gebruiken als er geen ordernummer bekend is.
    Zie ook UBL Verwijzing naar ReferentieGrootboekschema (RGS).

  10. [0..1] BuyerReference; referentie van de klant.

    PEPPOL BIS (PEPPOL-EN16931-R003)
    Een factuur moet een koperreferentie (BuyerReference) en/of een inkooporderreferentie (OrderReference) hebben.

    NLCIUS (BR-NL-2)
    Een factuur moet een koperreferentie (BuyerReference) en/of een inkooporderreferentie (OrderReference) hebben.
    Extra toelichting:
    In de referentie afnemer wordt een referentie opgenomen die door de afnemer bij bestelling is gegeven, of (als dat niet is gebeurd) een referentie die het de afnemer mogelijk maakt de factuur goed te keuren (bijvoorbeeld de naam van de besteller).
      
  11. [0..n] InvoicePeriod; Periode waarover de factuurprestatie is verricht.
    [0..1] EU-N 
    Via dit element  kan een factuurperiode wordt opgegeven, die dan bestaat uit de onderliggende elementen
        [0..1] StartDate
        [0..1] EndDate
        Formaat datum is in beide gevallen "YYYY-MM-DD".

        [0..n] DescriptionCode; Value added tax point date code
        [0..1] EU-N
       
        PEPPOL BIS

        De code (UNCL 2005 D.16B) van de datum waarop de btw verschuldigd wordt voor de verkoper en voor de koper.
        Zie aparte codelijst.

        NLCIUS (BR-NL-21)
        Het element "DescriptionCode" wordt afgeraden. 

        Advies UBL Ketentest
        Niet opnemen.
Opbouw UBL Factuur, factuurregels (InvoiceLine)

Een factuurregel kan een bijzonder uitgebreid aantal elementen bevatten, waarvan de meeste elementen optioneel zijn.
Minimaal 1 factuurregel is verplicht.

Links naar andere websites over [ RGS ]
Boekhoudplaza
RGS informatie voor softwareleveranciers en gebruikers. Met RGS Dashboard, RGS-schema met filters en WIKI RGS.
LinkedIN groep over RGS
Discusseer mee met de LinkedIN groep RGS/Auditfiles/SBR.
RGS website
Website die vooral de documentatie rondom RGS bevat.
Boekhoudplaza: de vindplaats voor RGS MKB
RGS MKB is het standaard decimaal rekeningschema voor het MKB. Met tevens een relatie naar rapportages en modellen voor kengetallen.
Softwarepakketten met [ RGS ] Leverancier
ManageMent Systeem
Het online kwaliteitszorgsysteem
Inception

Onerzoeksbureau GBNED