GST-factuur datamodel: minimale velden voor HSN en bestellingen

Wat er meestal misgaat met GST-facturen

De meeste problemen met GST-facturen zijn geen “complexe belasting”-kwesties. Het zijn ontbrekende of inconsistente gegevens. Een audit faalt wanneer de factuur niet helder terug te brengen is naar wat er verkocht is, aan wie, waar het geleverd is en hoe de belasting is berekend.

Een veelvoorkomende trigger is dat HSN ontbreekt, verouderd is of op het verkeerde niveau wordt toegepast. Teams slaan soms een HSN op het product op, maar de factuurregel wordt aangemaakt van een andere SKU-naam of variant, waardoor de HSN nooit op het uiteindelijke document terechtkomt. Een ander frequent probleem is de verkeerde belastingverdeling: IGST in rekening brengen terwijl het CGST en SGST had moeten zijn (of andersom) omdat de “plaats van levering” werd gegokt op basis van het afleveradres zonder de gebruikte state codes op te slaan.

Finance-teams voelen dit direct. Reconciliatie wordt een dagelijkse opruimtaak: factuurtotalen kloppen niet met de order, de order komt niet overeen met de betalingsoverzicht van de gateway en terugbetalingen worden een keten van handmatige aantekeningen. Zelfs kleine afrondingsverschillen over regellijsten kunnen mismatches veroorzaken tussen de factuur-PDF, GST-rapporten en het grootboek.

Dit zijn de patronen die de meeste pijn bij mismatches veroorzaken:

• Product- en factuurregels delen niet dezelfde HSN, GST-tarief en belastbare waarde-velden.
• Belasting wordt op meer dan één plek berekend (winkelwagen vs factuur) en de resultaten verschillen.
• Totalen worden alleen als “eindtotaal” opgeslagen zonder uitsplitsing voor belastbare waarde en elk belastingcomponent.
• Factuurnummering is bewerkbaar of gedupliceerd over reeksen.
• Terugbetalingen worden als negatieve orders vastgelegd in plaats van juiste creditnota's.

Het doel van een GST-factuur datamodel is eenvoudig: bewaar een minimale set order-, product-, partij-, belasting-, factuur- en creditnota-velden zodat elk bedrag later gereproduceerd en verklaard kan worden. Houd het compact, maar verwijder geen wettelijk belangrijke velden die het belastingtype, tarief en rapportage bepalen.

De kleinste set records die je nodig hebt

Als je wilt dat GST-facturen makkelijk te genereren en eenvoudig te reconciliëren zijn, begin dan met een kleine set objecten en laat elk object één taak doen. Een schoon GST-factuur datamodel gaat minder over veel tabellen en meer over feiten die stabiel blijven in de tijd.

Hier zijn de kernrecords die de meeste teams op dag één nodig hebben:

• Klant: wie kocht (naam, telefoon/e-mail, GSTIN als B2B)
• Adres: verzending en facturatie, plus staat en plaats-van-voorziening signalen
• Product (of Dienst): wat verkocht is, met eenheid, basisprijs en standaard HSN/SAC
• Order: het commerciële evenement (winkelwagen, kortingen, verzendkosten, status)
• Betaling: hoe geld bewoog (gateway-reference, methode, vastgelegd bedrag, datum)

Een Factuur moet gescheiden zijn van een Order. Orders kunnen veranderen (adres bewerkt, artikelen geannuleerd, gedeeltelijke levering). Facturen mogen dat niet. Ze hebben stabiele nummering, data en totalen die nooit "afdrijven" omdat iemand later een order bijgewerkt heeft.

Het anker voor belastingnauwkeurigheid zijn Regelitems. Elke orderregel (en later elke factuurregel) moet de exacte hoeveelheid, eenheidsprijs, korting en belastinguitsplitsing voor dat specifieke item bevatten. Daar worden HSN/SAC en GST-tarieven daadwerkelijk toegepast.

Een detail dat finance-teams veel tijd bespaart: sla snapshots op. Wanneer je een factuur genereert, kopieer dan de productomschrijving, HSN/SAC, belastingtarief en prijsstelling naar de factuurregels. Vertrouw niet op de huidige productmaster, want tarieven en namen veranderen.

Optioneel maar vaak vroeg de moeite waard zijn Retouren, Terugbetalingen en Creditnota's als aparte records. Voorbeeld: als een klant één artikel retourneert van een twee-artikelen order, wil je een creditnota die verwijst naar de originele factuurregel, terwijl het betalings-refund record verwijst naar de gateway-transactie. Deze expliciete objecten voorkomen maandafsluitings-“handmatige fixes” in GST-registers.

Als je dit in Koder.ai bouwt, behandel elk object eerst als een eenvoudig scherm (aanmaken, bekijken, bewerken) en voeg factuurgeneratie pas toe nadat snapshots en regel-niveau velden aanwezig zijn.

HSN en SAC: waar ze in het model passen

HSN (voor goederen) en SAC (voor diensten) zijn geen "alleen factuur"-gegevens. Ze beginnen bij de product- of dienstdefinitie en worden vervolgens gekopieerd naar elke factuurregel op het moment dat je de factuur opstelt. Dit houdt gemengde winkelwagens correct en maakt audits eenvoudiger omdat elke regel op zichzelf staat.

Een praktisch minimaal datamodel is:

• Product: id, naam, SKU, eenheid (UOM), base_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code
• InvoiceLine: id, invoice_id, product_id (optioneel voor handmatige regels), description, unit, qty, unit_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code

HSN/SAC op het Product plaatsen helpt je admin-team het op één plek te onderhouden. Het kopiëren naar InvoiceLine is wat oude facturen stabiel maakt. Zelfs als het product later verandert, toont de factuur nog wat waar was op het moment van verkoop. Dit is de kern van een GST-factuur datamodel dat tijdens reconciliatie niet breekt.

Voor HSN-opslag, houd het simpel: code is verplicht, beschrijving is optioneel, en een effective_from datum is optioneel als je een wijzigingshistorie wilt. De meeste teams hebben de beschrijving niet op elke regel nodig, maar het kan helpen bij finance-controles van uitzonderingen.

Gemengde winkelwagens zijn normaal: één factuur kan meerdere regelitems en dus meerdere HSN/SAC-codes bevatten. Probeer niet één code per factuur af te dwingen. Totalen rollen op op factuurniveau, terwijl classificatie op regelniveau blijft.

Change management is waar mensen problemen krijgen. Gebruik een klein regelsetje:

• Overschrijf nooit HSN/SAC op uitgegeven factuurregels.
• Als het HSN/SAC van een product verandert, werk het Product bij voor toekomstige orders alleen.
• Als je geschiedenis bijhoudt, voeg een nieuw effective_from record toe in plaats van het oude te bewerken.

Qua admin-schermen heb je slechts één plek nodig om Product belastingvelden te bewerken, plus een read-only weergave op de factuurregel om te bevestigen wat er werd vastgelegd toen de factuur werd aangemaakt. Als je deze schermen snel bouwt, kunnen tools zoals Koder.ai de basale CRUD-pagina's en datatabellen genereren vanuit dit model met minimale inspanning.

Partijgegevens: GSTIN, adressen en plaats van voorziening

Een GST-factuur datamodel faalt het meest op partijgegevens. Als de identiteit van koper of verkoper ook maar iets afwijkt, kan je factuur wel op papier geldig zijn maar pijnlijk in aangiften en reconciliatie.

Begin met het behandelen van “verkoper”, “koper” en “ship-to” als afzonderlijke partijen, ook als het dezelfde persoon is. Dit voorkomt latere hacks wanneer een klant een ander afleveradres toevoegt of wanneer je verkoopt vanuit meer dan één GST-registratie.

Minimale velden om op te slaan (koper en verkoper)

Houd de velden saai en expliciet. Dit zijn de velden die meestal nodig zijn op de factuur en in rapporten:

• Juridische naam (zoals op de factuur moet verschijnen)
• Handelsnaam (optioneel, maar nuttig)
• GSTIN (verkoper vereist; koper nullable)
• Telefoon/e-mail (niet altijd verplicht, maar handig voor support)
• Adresregels, stad, staat, land, PIN/postcode

Sla de staat zowel als mensleesbare naam als als state code op, omdat rapportage en plaats-van-voorziening regels vaak op de code vertrouwen.

Facturatie versus verzending en plaats van voorziening

Sla zowel factuur- als verzendadressen op de order op, niet alleen in het klantprofiel. Profielen veranderen; facturen niet.

Plaats van voorziening moet als een specifieke state code op de factuur worden opgeslagen (gekopieerd van de order op het moment van facturatie). Bereken deze later niet opnieuw. Als je regel “ship-to state” is, sla dat resultaat op, plus de staat die gebruikt is om die beslissing te nemen. Dit maakt audits en geschillen eenvoudiger.

B2B versus B2C: wanneer GSTIN verplicht is

Voor B2B is de GSTIN van de koper normaal vereist en moet die bij invoer op lengte en formaat worden gevalideerd. Voor B2C kan GSTIN leeg blijven, maar je hebt nog steeds een volledig adres en staat nodig om te bepalen of CGST/SGST of IGST van toepassing is.

Een eenvoudige regel die in de meeste systemen werkt: als buyer GSTIN aanwezig is, behandel als B2B; als niet, behandel als B2C. Als je uitzonderingen nodig hebt, sla een expliciet customer_type veld op.

Multi-entity verkopers (meerdere GSTINs)

Als je vestigingen of business units hebt met verschillende GST-registraties, modelleer “Seller Entity” als een eigen record met eigen GSTIN en adres. Elke order moet precies één seller entity refereren en elke factuur moet die details kopiëren zodat historische facturen accuraat blijven, zelfs als het verkoperadres later verandert.

Tools zoals Koder.ai kunnen snel de admin-formulieren voor deze records genereren, maar de sleutel is de structuur: aparte seller entity, order-time snapshots en een expliciete place-of-supply state code.

Belastingberekeningsvelden die je moet opslaan

De meest voorkomende splitsing is simpel: als de plaats van voorziening in dezelfde staat ligt als de leverancier, is de belasting CGST + SGST. Als het een andere staat is, is de belasting IGST. Je systeem moet dit later niet opnieuw berekenen vanuit totalen omdat kleine verschillen (afronding, kortingen, verzending) precies zijn wat mismatches veroorzaakt.

Minimaal moet je belastingnummers op factuurregelniveau opslaan, niet alleen in de factuurheader. Zo kun je elke rupee op de factuur verklaren en terugkoppelen naar product, HSN en omzet.

Een praktisch minimum per factuurregel in je GST-factuur datamodel ziet er zo uit:

• taxable_value (na toewijzing van regel-niveau korting)
• gst_rate_percent
• cgst_rate_percent, sgst_rate_percent, igst_rate_percent (sla de gebruikte splitsing op)
• cgst_amount, sgst_amount, igst_amount (sla de berekende bedragen op)
• line_total (taxable_value + belastingbedragen)

Kortingen zijn waar systemen rommelig worden. Bepaal één regel en sla die duidelijk op. Als kortingen de prijs vóór belasting verlagen (typisch voor artikelkortingen en coupons), sla dan het oorspronkelijke bruto bedrag, het kortingsbedrag en de resulterende taxable value op. Als je een order-niveau coupon hebt, wijs deze toe over lijnen (meestal proportioneel aan elke regel's voor-korting taxable value) en sla elke regel's toegewezen korting op zodat je belastingberekening verklaarbaar blijft.

Afronding moet consistent zijn en vastgelegd worden. Kies of je afrondt op regelniveau of alleen op factuurniveau en sla dan de afgeronde resultaten op die je hebt afgedrukt. Veel teams berekenen belasting per regel, ronden op 2 decimalen, tellen op en passen vervolgens een finale invoice_rounding_adjustment toe om tot het exacte betaalbare bedrag te komen.

Verzending en handling mag geen verborgen toeslag zijn. Behandel deze als een aparte factuurregel met een eigen HSN/servicecode en belastingregel. Bijvoorbeeld: een order met twee producten en een verzendkostenregel wordt drie regels, elk met opgeslagen taxable value en belastingcomponentbedragen, wat finance-reconciliatie veel eenvoudiger maakt.

Gegevens op het factuurdocument: nummering, data, totalen, status

Als belasting eenmaal berekend is, heeft de factuur nog steeds “document” velden nodig die het geldig, controleerbaar en makkelijk te reconciliëren maken. Behandel de factuurheader in een GST-factuur datamodel als een juridisch record: het moet stabiel blijven zelfs als product- of klantgegevens in de toekomst veranderen.

Begin met de header basics: factuurnummer, uitgiftedatum (de datum op de factuur), factuurtype (tax invoice, export, B2B, B2C, enz.) en valuta. Zelfs als je voornamelijk in INR factureert, voorkomt het opslaan van valuta moeilijke randgevallen bij export of multi-currency marktplaatsen.

Nummering is waar teams vaak problemen krijgen. Houd een serie of prefix (bijvoorbeeld “FY25-INV-”), sla het financiële jaar op en handhaaf uniciteit op databaseniveau. Sla ook “next number” controles per serie in admin op zodat twee admins niet tegelijk hetzelfde nummer kunnen toewijzen.

Totalen moeten expliciet worden opgeslagen, niet alleen afgeleid. Bewaar subtotalen (taxable value), totale belasting, eindtotaal en een apart afrondingsbedrag. Als je later uit regellijsten herberekent, kan een kleine regelwijziging ertoe leiden dat oude facturen niet meer overeenkomen met de ingediende aangifte.

Statussen moeten de echte levenscyclus weergeven en het record vergrendelen wanneer nodig:

• Draft (bewerkbaar)
• Issued (nummer toegewezen, PDF gegenereerd)
• Cancelled (bewaard voor audit, niet verwijderd)
• Refunded (betaling teruggedraaid, kan creditnota vereisen)
• Credit noted (gerelateerde creditnota uitgegeven)

Tot slot sla gegenereerde artefactmetadata op: PDF-template versie, gegenereerde timestamp en een bestandsidentifier. Een hash is optioneel, maar nuttig als je moet bewijzen dat de PDF niet is aangepast.

Voorbeeld: als een supportmedewerker een PDF opnieuw genereert na een template-update, moeten de factuurtotalen en het nummer identiek blijven, maar de opgeslagen templateversie verklaart waarom het PDF-layout er anders uitziet.

Adminschermen voor producten, belastingen en klantgegevens

Als je schone GST-facturen wilt, begin dan niet met het factuurscherm. Begin met de adminpagina's die ernaartoe voeren. Een goed GST-factuur datamodel blijft compact als deze invoer gecontroleerd en consistent is.

Productmaster (SKU naar HSN/SAC)

De productmaster is waar de meeste toekomstige mismatches beginnen, dus houd het strikt. Elke SKU moet precies één standaard HSN (of SAC voor diensten) hebben, plus een standaard GST-tarief en eventuele uitzonderingen die alleen voor bepaalde datums gelden.

Een praktisch productscherm heeft meestal:

• SKU en productnaam (zoals je het op de factuur wilt laten verschijnen)
• HSN/SAC code, GST-tarief en belastingcategorie (als je die gebruikt)
• Active from/to data (zodat wijzigingen oude facturen niet herschrijven)
• Prijs-overrides (voor speciale MRP's of kanaalspecifieke prijzen)
• Status (actief/inactief) met een duidelijke reden voor deactivering

Belastinginstellingen (tarieven en intra- vs inter-state inputs)

Vermijd een “calculator” UI. Sla in plaats daarvan de invoer op die je systeem consequent kan toepassen: tarieftabellen, plaats-van-voorziening regels die je volgt en hoe je intra-state versus inter-state bepaalt (meestal door leverancierstaat en ship-to staat te vergelijken).

Houd het belastingscherm gefocust op: belastingtarief per categorie/HSN-groep, ingangsdata en wat moet gebeuren als de koper een geldige GSTIN opgeeft versus niet.

Klant- en bedrijfsprofiel (wie op de factuur staat)

Het klantscherm moet GSTIN en de validatiestatus vastleggen, plus standaard factuur- en verzendadressen. Laat gebruikers geen vrije tekst voor staten typen; gebruik een gecontroleerde lijst zodat “KA” en “Karnataka” niet twee verschillende waarden worden.

Je bedrijfsprofielscherm is even belangrijk: juridische naam, GSTIN, geregistreerd adres en factuurnummerreeksinstellingen (prefix, next number en grenzen van het financiële jaar). Beperk dit met permissies omdat wijzigingen elke toekomstige document beïnvloeden.

Basis auditlog (vertrouwen en traceerbaarheid)

Je hebt geen complex systeem nodig, maar je hebt wel een spoor nodig. Log wie HSN/SAC, GST-tarieven, factuurnummerreeksinstellingen of company GSTIN heeft gewijzigd, samen met de oude waarde, nieuwe waarde, timestamp en reden.

Als je deze schermen in een tool als Koder.ai bouwt, behandel audit logging en effective dates als eersteklas velden vanaf dag één. Ze kosten weinig om vroeg toe te voegen en besparen uren tijdens finance reviews later.

Stap voor stap: van order naar conforme factuur

Een conforme factuur gaat minder over mooie opmaak en meer over het bevriezen van de juiste feiten op het juiste moment. Als je je GST-factuur datamodel rond deze flow ontwerpt, wordt finance-werk een simpele match in plaats van een wekelijkse zoektocht.

1) Bevries wat de klant daadwerkelijk kocht

Voordat je belasting berekent, maak een order-snapshot: items, hoeveelheden, eenheidsprijzen, kortingen, verzend-/handlingkosten, klant-GSTIN (indien aanwezig), factuur- en verzendadressen en place-of-supply signalen. De snapshot mag niet veranderen, zelfs als de productprijs of HSN-mapping later verandert.

2) Zet snapshot om in factuurregels (met gekopieerde belastingattributen)

Bereken belastingen en genereer factuurregels vanuit de snapshot. Elke factuurregel moet HSN/SAC, belastingtarief(len), taxable value en gebruikte belastingbedragen op dat moment kopiëren in plaats van ze later live op te zoeken.

3) Geef de factuur uit en maak deze onveranderlijk

Wijs het factuurnummer en de uitgiftedatum toe en markeer de factuur als uitgegeven. Blokkeer vanaf dat punt bewerkingen aan prijzen, belastingtarieven, HSN-codes en adressen op het factuurrecord. Als je iets moet toestaan, beperk het tot niet-financiële notities en interne tags.

4) Produceer het einddocument en sla de totalen op

Genereer de PDF/printweergave van de uitgegeven factuur en sla daarna de finale totalen op die je zult rapporteren: taxable total, CGST/SGST/IGST totalen, afronding en eindtotaal. Als extra zekerheid kun je een documentversie of checksum opslaan zodat je kunt bewijzen dat de print overeenkomt met de opgeslagen cijfers.

5) Handel wijzigingen op wettelijke wijze af

Na uitgifte moeten wijzigingen volgens regels gebeuren, niet door bewerkingen:

• Klant wil prijscorrectie: maak een creditnota (of debitnota) die verwijst naar de originele factuur.
• Order wordt geannuleerd na uitgifte: annuleer de factuur als toegestaan, anders geef een creditnota uit.
• Klant wijzigt adres na uitgifte: herschrijf de factuur niet; corrigeer via het juiste document en houd een audittrail bij.
• Gedeeltelijke terugbetaling: creditnota voor alleen de terugbetaalde regels/bedrag.
• Vervangende zending: nieuwe order/factuur, geen stille bewerking.

Als je deze flow in je adminschermen bouwt (Koder.ai-stijl planning mode is nuttig om de stappen in kaart te brengen voordat je bouwt), kan je team facturen snel genereren zonder later reconciliatie te breken.

Maak reconciliatie pijnloos: betalingen, terugbetalingen en registers

Reconciliatie wordt rommelig wanneer betalingen worden behandeld als een enkele “betaald/onbetaald” vlag op de order. Houd betalingen en terugbetalingen als aparte records die naar de order en de factuur verwijzen, zodat finance bankafstemmingen kan matchen zonder de geschiedenis te herschrijven.

Scheid betaling en terugbetaling records (bewerk de factuur niet)

Een conforme factuur moet stabiel blijven nadat deze is uitgegeven. Als een klant in termijnen betaalt of je later terugbetaalt, registreer die beweging als een betaling of terugbetaling, niet als een wijziging van de factuurtotalen.

Minimale velden die meestal reconciliatie eenvoudig maken:

• Payment: payment_id, order_id, invoice_id, method, gateway_name, gateway_payment_id, amount, currency, authorized_at, captured_at, settlement_date, status
• Settlement (optioneel maar nuttig): settlement_id, gateway_payout_id, settlement_date, gross_amount, fees, net_amount
• Refund: refund_id, order_id, invoice_id, payment_id, credit_note_id (indien uitgegeven), gateway_refund_id, amount, reason, refunded_at, status
• Reconciliatie sleutels die je nooit moet hergebruiken: order_id, invoice_id, payment_id, refund_id, credit_note_id

Als de klant één artikel retourneert, “verminder” de factuur dan niet. Geef een creditnota uit en koppel die aan de originele factuur. Het factuurregister blijft schoon en de terugbetaling koppelt terug naar de creditnota.

Finance-weergave en exports die uren besparen

Geef finance één scherm dat antwoordt op: wat is uitgegeven, wat is betaald, wat staat nog open en wat is omgekeerd. Voeg ageing toe (0-7, 8-30, 31-60, 60+ dagen) en mogelijkheid om door te klikken naar gerelateerde betaling- en terugbetalingsentries.

Exports die de meeste teams maandelijks nodig hebben:

• Factuurregister (uitgegeven, geannuleerd, creditgenoteerd)
• Belastingoverzicht per tarief en HSN/SAC (ondersteunt je GST-factuur datamodel)
• Betaling versus factuur reconciliatie (invoice_id, betalingstotalen, saldo)
• Terugbetalingen- en creditnotaregister
• Gateway settlement rapport (payout_id naar invoice/payment mapping)

Voorbeeld: een order is Rs 10,000, betaald Rs 6,000 vandaag en Rs 4,000 volgende week. De factuur blijft Rs 10,000. Je finance-weergave toont een saldo van Rs 4,000 totdat de tweede afwikkeling arriveert en markeert het daarna als volledig betaald zonder het uitgegeven document te wijzigen.

Veelvoorkomende valkuilen die compliance- en mismatchproblemen veroorzaken

De meeste GST-factuurproblemen zijn geen “belastinglogica”-problemen. Het zijn boekhoudkundige problemen: de cijfers op de PDF komen niet overeen met wat finance exporteert of de factuur kan maanden later niet worden verklaard.

De eerste valkuil is GST alleen bij weergave berekenen. Als je CGST/SGST/IGST elke keer berekent wanneer iemand een factuur opent, krijg je uiteindelijk verschillende resultaten na een tariefwijziging, afrondingsregelwijziging of bugfix. Sla de berekende belastinguitsplitsing op die gebruikt is toen de factuur werd uitgegeven, zelfs als je ook de inputs bewaart.

Een tweede valkuil is het toestaan van bewerkingen aan een uitgegeven factuur. Zodra een factuur definitief is, moeten wijzigingen via een creditnota of vervangingsflow met audittrail gebeuren. Anders krijg je discussies van het type “waarom verschilt de klant-PDF met de boeken?”.

Dit zijn mismatch-patronen die het meest voorkomen in een GST-factuur datamodel:

• Plaats van voorziening ontbreekt of de state code is fout, waardoor IGST wordt toegepast terwijl CGST+SGST van toepassing had moeten zijn (of omgekeerd).
• Product HSN/SAC of belastingtarief wordt bijgewerkt en oude orders worden herberekend met de nieuwe waarde.
• Belasting is opgeslagen, maar afrondingsregels verschillen tussen UI, PDF-generatie en CSV-exports.
• Kortingen worden op de ene plek na belasting toegepast en op de andere plek vóór belasting.
• Terugbetalingen worden vastgelegd als negatieve regellijsten zonder duidelijke koppeling naar de originele factuur.

Een snel voorbeeld: je verkoopt aan een klant in Karnataka, maar het afleveradres is in Maharashtra. Als je systeem per ongeluk de facturatiestaat kiest voor plaats van voorziening, kun je CGST+SGST in rekening brengen in plaats van IGST. Als je daarbij belasting dynamisch opnieuw berekent, kan die fout later stilletjes “genezen”, waardoor finance met cijfers blijft zitten die niet overeenkomen met het uitgegeven document.

Wanneer je adminschermen bouwt (of via een platform zoals Koder.ai), voeg kleine vangrails toe: vergrendel uitgegeven facturen, toon plaats-van-voorziening invoer naast het berekende belastingtype en houd een onveranderlijke snapshot van HSN, tarief en afronding die bij uitgifte is gebruikt.

Snelle checklist en vervolgstappen

Voordat je een factuur naar een klant stuurt of markeert als “uitgegeven”, voer een snelle set checks uit. Hier ontstaan de meeste kleine fouten die later tot grote reconciliatieproblemen leiden. Als je een GST-factuur datamodel bouwt, is het de moeite waard om deze checks in zowel validatieregels als je admin-UI in te bouwen.

Per-factuur checks (voordat je uitgeeft)

• HSN/SAC is aanwezig op elke regel en komt overeen met het product of de dienst die je daadwerkelijk verkocht hebt.
• GSTIN-regels zijn correct toegepast (B2B vs B2C) en facturatie- en verzendgegevens spreken elkaar niet tegen.
• Plaats van voorziening is opgeslagen en de belastingverdeling is logisch (CGST/SGST vs IGST).
• Totalen tellen exact op: taxable value, elk belastingcomponent, afronding en eindtotaal.
• Zodra uitgegeven, is de factuur vergrendeld (geen stille bewerkingen). Correcties gebeuren via creditnota of annuleringsflow, niet door de geschiedenis te herschrijven.

Een simpel voorbeeld: een klant werkt na betaling zijn afleveradres bij en de staat verandert. Als je hetzelfde factuurnummer opnieuw uitgeeft met nieuwe belasting, stoppen je register en betalingsrecords met overeenkomen. De veiligere aanpak is het oorspronkelijke factuur onveranderlijk te houden en een correctiedocument aan te maken.

Data + workflow checks (om finance schoon te houden)

• Factuurnummering is uniek, sequentieel volgens je beleid en wordt alleen gegenereerd bij “uitgifte”.
• Sla de berekende belastingbedragen op die je hebt gebruikt, niet alleen de tarieven, zodat rapporten stabiel blijven zelfs als tarieven later veranderen.
• Duidelijke statusstappen bestaan: concept -> uitgegeven -> geannuleerd (en aparte creditnota-documenten).
• Rapporten reconciliëren per periode: factuurregistertotalen moeten overeenkomen met betalingen vastgelegd, verwerkte terugbetalingen en openstaande vorderingen.
• Auditvelden zijn altijd aanwezig: aangemaakt door, uitgegeven op en een reden-opmerking voor annuleringen of creditnota's.

Vervolgstappen: implementeer eerst de schermen en validaties, en iterateer daarna. In Koder.ai begin je in Planning Mode om de records en adminschermen te schetsen (producten met HSN/SAC-mapping, klant/GSTIN-gegevens, belastingregels en facturen). Genereer de app, test een paar echte orders end-to-end en gebruik snapshots en rollback om veilig de workflow te verfijnen. Wanneer je diepere aanpassingen of reviews nodig hebt, exporteer de broncode en blijf evolueren volgens je gebruikelijke proces.