Modèle de données de facture GST : champs minimaux pour HSN et commandes

Ce qui cloche généralement avec les factures GST

La plupart des problèmes de facturation GST ne sont pas des problèmes de « fiscalité complexe ». Ce sont des problèmes de données manquantes ou incohérentes. Un audit échoue quand la facture ne peut pas être reliée proprement à ce qui a été vendu, à qui, où la fourniture a eu lieu et comment la taxe a été calculée.

Un déclencheur fréquent est l'absence, l'obsolescence ou l'application au mauvais niveau du HSN. Les équipes peuvent stocker un HSN sur le produit, mais la ligne de facture est créée à partir d'un autre nom de SKU ou d'un variant, si bien que le HSN n'atteint jamais le document final. Un autre problème fréquent est une mauvaise répartition des taxes : facturer IGST alors qu'il aurait fallu CGST et SGST (ou inversement) parce que le « lieu d'approvisionnement » a été deviné depuis l'adresse de livraison sans stocker les codes d'état utilisés pour la décision.

Les équipes financières ressentent cela immédiatement. La réconciliation devient un travail de nettoyage quotidien : les totaux de la facture ne correspondent pas à la commande, la commande ne correspond pas au règlement de la passerelle de paiement, et les remboursements deviennent une chaîne de notes manuelles. Même de petites différences d'arrondi entre les lignes peuvent créer des discordances entre le PDF de la facture, les rapports GST et le grand livre.

Voici les motifs qui causent le plus de douleur lors des rapprochements :

• Les produits et les lignes de facture n'ont pas les mêmes champs HSN, taux de GST et valeur taxable.
• La taxe est calculée à plusieurs endroits (panier vs facture) et les résultats diffèrent.
• Les totaux sont stockés uniquement comme « montant global » sans ventilation pour la valeur taxable et chaque composante fiscale.
• La numérotation des factures est modifiable ou dupliquée entre séries.
• Les remboursements sont enregistrés comme des commandes négatives au lieu de notes de crédit appropriées.

L'objectif d'un modèle de données de facture GST est simple : stocker un ensemble minimal de champs pour la commande, le produit, les parties, la taxe, la facture et les notes de crédit afin que chaque montant puisse être reproduit et expliqué ultérieurement. Gardez le modèle restreint, mais ne supprimez pas les champs légalement importants qui déterminent le type de taxe, le taux et le reporting.

L'ensemble minimal d'enregistrements dont vous avez besoin

Si vous voulez que les factures GST soient faciles à générer et à rapprocher ensuite, commencez par un petit ensemble d'objets et faites en sorte que chacun ait une seule responsabilité. Un modèle de données propre pour la facture GST tient moins à la multiplication des tables qu'à la stabilité des faits au fil du temps.

Voici les enregistrements de base dont la plupart des équipes ont besoin dès le premier jour :

• Client : qui a acheté (nom, téléphone/email, GSTIN si B2B)
• Adresse : livraison et facturation, plus les signaux d'état et de lieu d'approvisionnement
• Produit (ou service) : ce qui a été vendu, avec unité, prix de base et HSN/SAC par défaut
• Commande : l'événement commercial (panier, remises, frais de livraison, statut)
• Paiement : comment l'argent a bougé (référence passerelle, méthode, montant capturé, date)

Une Facture doit être distincte d'une Commande. Les commandes peuvent changer (adresse modifiée, articles annulés, exécution partielle). Les factures ne doivent pas changer. Elles ont besoin d'une numérotation stable, de dates et de totaux qui ne « dérivent » pas parce que quelqu'un a modifié une commande plus tard.

L'ancre de la précision fiscale est les Lignes de facture. Chaque ligne de commande (et plus tard chaque ligne de facture) doit contenir la quantité exacte, le prix unitaire, la remise et la ventilation fiscale pour cet article spécifique. C'est là que le HSN/SAC et les taux GST sont appliqués.

Un détail qui sauve les équipes financières : stocker des snapshots. Lors de la génération d'une facture, copiez la description du produit, le HSN/SAC, le taux de taxe et le prix dans les lignes de facture. Ne vous fiez pas au produit maître actuel, car les taux et les noms changent.

Il est facultatif mais souvent utile d'ajouter tôt des enregistrements séparés pour les Retours, Remboursements et Notes de crédit. Exemple : si un client retourne un article d'une commande de deux articles, vous souhaitez une note de crédit qui référence la ligne de facture d'origine, tandis que l'enregistrement de remboursement référence la transaction de la passerelle. Les garder comme objets explicites évite les « corrections manuelles » en fin de mois dans les registres GST.

Si vous construisez cela dans Koder.ai, traitez chaque objet d'abord comme un écran simple (créer, voir, modifier), puis ajoutez la génération de facture uniquement après que les snapshots et les champs au niveau des lignes sont en place.

HSN et SAC : où les placer dans le modèle

HSN (pour les biens) et SAC (pour les services) ne sont pas des détails « réservés à la facture ». Ils commencent à la définition du produit ou du service, puis sont copiés sur chaque ligne de facture au moment de l'émission. Cela maintient les paniers mixtes corrects et facilite les audits car chaque ligne est autonome.

Un modèle de données minimal pratique est :

• Product : id, name, SKU, unit (UOM), base_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code
• InvoiceLine : id, invoice_id, product_id (optionnel pour lignes manuelles), description, unit, qty, unit_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code

Placer le HSN/SAC sur le Product aide votre équipe admin à le maintenir en un seul endroit. Le copier dans InvoiceLine rend les factures passées stables. Même si le produit change plus tard, la facture montre ce qui était vrai au moment de la vente. C'est le cœur d'un modèle de données GST qui ne casse pas lors des rapprochements.

Pour le stockage du HSN, gardez-le simple : le code est requis, la description est optionnelle, et une date effective (effective_from) est optionnelle si vous voulez un historique des changements. La plupart des équipes n'ont pas besoin de la description sur chaque ligne, mais cela peut aider quand la finance vérifie des exceptions.

Les paniers mixtes sont normaux : une facture peut contenir plusieurs lignes et donc plusieurs codes HSN/SAC. N'essayez pas d'imposer un seul code par facture. Les totaux s'agrègent au niveau de la facture tandis que la classification reste au niveau des lignes.

La gestion des changements est un point d'accroche courant. Utilisez un petit ensemble de règles :

• Ne jamais écraser le HSN/SAC sur des lignes de facture émises.
• Si le HSN/SAC d'un produit change, mettez à jour le Product pour les commandes futures uniquement.
• Si vous suivez l'historique, ajoutez un nouvel enregistrement effective_from plutôt que d'éditer l'ancien.

Côté écrans admin, il suffit d'un endroit pour éditer les champs fiscaux produit, plus une vue en lecture seule sur la ligne de facture pour confirmer ce qui a été capturé lors de la création de la facture. Si vous construisez ces écrans rapidement, des outils comme Koder.ai peuvent générer les pages CRUD de base et les tableaux de données à partir de ce modèle avec un minimum d'effort.

Détails des parties : GSTIN, adresses et lieu d'approvisionnement

Un modèle de données de facture GST échoue le plus souvent sur les détails des parties. Si l'identité de l'acheteur ou du vendeur est même légèrement incorrecte, votre facture peut être valide sur le papier mais problématique dans les déclarations et la réconciliation.

Commencez par traiter « vendeur », « acheteur » et « destinataire » comme des parties séparées, même lorsqu'il s'agit de la même personne. Cela évite des bricolages ultérieurs quand un client ajoute une adresse de livraison différente ou quand vous vendez à partir de plusieurs enregistrements GST.

Champs minimaux à stocker (acheteur et vendeur)

Gardez les champs simples et explicites. Ce sont ceux dont on a généralement besoin sur la facture et dans les rapports :

• Raison sociale (telle qu'elle doit apparaître sur la facture)
• Nom commercial (optionnel, mais utile)
• GSTIN (obligatoire pour le vendeur ; acheteur nullable)
• Téléphone/email (pas toujours obligatoire, mais utile pour le support)
• Lignes d'adresse, ville, état, pays, code postal

Stockez l'état à la fois comme nom lisible et comme code d'état, car le reporting et les règles de lieu d'approvisionnement reposent souvent sur le code.

Facturation vs livraison et lieu d'approvisionnement

Capturez à la commande à la fois les adresses de facturation et de livraison, pas seulement sur le profil client. Les profils changent ; les factures ne doivent pas.

Le lieu d'approvisionnement doit être stocké comme un code d'état spécifique sur la facture (copié depuis la commande au moment de la facturation). Ne le « recalculez » pas plus tard. Si votre règle est « état de livraison », stockez ce résultat, ainsi que l'état utilisé pour décider. Cela facilite audits et litiges.

B2B vs B2C : quand le GSTIN est obligatoire

Pour le B2B, le GSTIN de l'acheteur est généralement requis et doit être validé en longueur et format lors de la saisie. Pour le B2C, le GSTIN peut rester vide, mais vous avez toujours besoin d'une adresse complète et d'un état pour déterminer si CGST/SGST ou IGST s'applique.

Une règle simple qui marche dans la plupart des systèmes : si le GSTIN de l'acheteur est présent, traitez comme B2B ; sinon, traitez comme B2C. Si vous avez besoin d'exceptions, stockez un champ customer_type explicite.

Vendeurs multi-entités (plusieurs GSTIN)

Si vous avez des succursales ou des unités avec des immatriculations GST différentes, modélisez « Seller Entity » comme un enregistrement distinct avec son propre GSTIN et adresse. Chaque commande doit référencer exactement une entité vendeuse, et chaque facture doit copier ces détails pour que les factures historiques restent exactes même si l'adresse du vendeur change plus tard.

Des outils comme Koder.ai peuvent générer rapidement les formulaires admin pour ces enregistrements, mais l'essentiel est la structure : entité vendeur séparée, snapshots au moment de la commande, et un code d'état explicite pour le lieu d'approvisionnement.

Champs de calcul de la taxe à stocker

Le partage le plus courant est simple : si le lieu d'approvisionnement est dans le même état que le fournisseur, la taxe est CGST + SGST. Si c'est dans un état différent, la taxe est IGST. Votre système ne doit pas « recalculer plus tard à partir des totaux » parce que de petites différences (arrondi, remises, livraison) sont précisément ce qui cause des discordances.

Au minimum, stockez les montants fiscaux au niveau de la ligne de facture, pas seulement dans l'en-tête. Ainsi vous pouvez expliquer chaque roupie sur la facture et la rattacher au produit, au HSN et au revenu.

Un minimum pratique par ligne de facture dans votre modèle de données GST ressemble à ceci :

• taxable_value (après allocation de la remise au niveau ligne)
• gst_rate_percent
• cgst_rate_percent, sgst_rate_percent, igst_rate_percent (stocker la répartition utilisée)
• cgst_amount, sgst_amount, igst_amount (stocker les montants calculés)
• line_total (taxable_value + montants de taxe)

Les remises sont là où les systèmes se compliquent. Décidez d'une règle et stockez-la clairement. Si les remises réduisent le prix avant taxe (typique pour remises sur article et coupons), stockez le montant brut d'origine, le montant de la remise et la valeur taxable résultante. Si vous avez un coupon au niveau commande, répartissez-le sur les lignes (généralement proportionnellement à la valeur taxable pré-remise de chaque ligne) et stockez la remise allouée sur chaque ligne pour que la comptabilité fiscale reste explicable.

L'arrondi doit être cohérent et enregistré. Choisissez si vous arrondissez au niveau ligne ou uniquement au niveau facture, puis stockez les résultats arrondis que vous avez imprimés. Beaucoup d'équipes calculent la taxe par ligne, arrondissent à 2 décimales, font la somme, puis appliquent un champ invoice_rounding_adjustment final pour atteindre le montant payable exact.

Les frais de port et de manutention ne doivent pas être un ajout caché. Traitez-les comme une ligne de facture séparée avec son propre code HSN/service et règles de taux. Par exemple, une commande avec deux produits et des frais de livraison devient trois lignes, chacune avec valeur taxable et montants de taxe stockés, ce qui facilite grandement la réconciliation financière.

Données du document facture : numérotation, dates, totaux, statut

Une fois la taxe calculée, la facture a toujours besoin de champs « document » qui la rendent valide, vérifiable et facile à rapprocher ensuite. Dans un modèle de données facture GST, traitez l'en-tête de la facture comme un enregistrement légal : il doit être stable même si les données produit ou client changent dans le futur.

Commencez par les bases de l'en-tête : numéro de facture, date d'émission (la date sur la facture), type de facture (tax invoice, export, B2B, B2C, etc.) et devise. Même si vous facturez principalement en INR, stocker la devise évite des cas limites pour les exportations ou les places de marché multi-devises.

La numérotation est un point critique. Gardez une série ou un préfixe (par exemple FY25-INV-), stockez l'année financière et imposez l'unicité au niveau base de données. Stockez aussi des contrôles « prochain numéro » par série dans l'admin pour que deux admins ne puissent pas émettre le même numéro en même temps.

Les totaux doivent être stockés explicitement, pas seulement dérivés. Sauvegardez le sous-total (valeur taxable), le total taxe et le montant global, ainsi qu'un montant séparé d'arrondi. Si vous recalculer plus tard à partir des lignes, un petit changement de règle peut faire que d'anciennes factures ne correspondent plus aux déclarations déposées.

Les statuts doivent refléter le cycle de vie réel et verrouiller l'enregistrement quand c'est nécessaire :

• Draft (modifiable)
• Issued (numéro assigné, PDF généré)
• Cancelled (conservée pour audit, pas supprimée)
• Refunded (paiement inversé, peut nécessiter une note de crédit)
• Credit noted (note de crédit émise, liée)

Enfin, stockez les métadonnées des artefacts générés : version du template PDF, horodatage de génération et identifiant de fichier. Un hash est optionnel, mais utile si vous devez prouver que le PDF n'a pas été altéré.

Exemple : si un agent support régénère un PDF après une mise à jour du template, les totaux et le numéro de la facture doivent rester identiques, mais la version du template stockée explique pourquoi la mise en page du PDF est différente.

Écrans admin pour produits, taxes et données client

Si vous voulez des factures GST propres, ne commencez pas par l'écran facture. Commencez par les pages admin qui l'alimentent. Un bon modèle de données de facture GST reste petit lorsque ces entrées sont contrôlées et cohérentes.

Fiche produit (SKU vers HSN/SAC)

La fiche produit est là où la plupart des divergences futures commencent, donc soyez strict. Chaque SKU doit avoir exactement un HSN par défaut (ou SAC pour les services), plus un taux GST par défaut et les exceptions applicables seulement à certaines dates.

Un écran produit pratique a généralement :

• SKU et nom du produit (tel que vous voulez l'imprimer)
• Code HSN/SAC, taux GST et catégorie fiscale (si vous en utilisez une)
• Dates active from/to (pour que les changements ne réécrivent pas les anciennes factures)
• Overrides de prix (pour MRP spéciaux ou tarification par canal)
• Statut (actif/inactif) avec raison claire de désactivation

Configuration fiscale (taux et entrées intra vs inter-état)

Évitez une UI de type « calculatrice ». Stockez plutôt les entrées que votre système peut appliquer de façon cohérente : tables de taux, règles de lieu d'approvisionnement que vous suivez, et comment vous décidez intra-state vs inter-state (généralement en comparant l'état du fournisseur et l'état du destinataire).

Concentrez l'écran taxe sur : taux par catégorie/goupe HSN, dates effectives et ce qui doit se passer lorsque l'acheteur fournit un GSTIN valide ou non.

Profil client et entreprise (qui figure sur la facture)

L'écran client doit capturer le GSTIN et son statut de validation, plus les adresses par défaut de facturation et de livraison. N'autorisez pas la saisie d'états en texte libre ; utilisez une liste contrôlée pour que "KA" et "Karnataka" ne deviennent pas deux valeurs différentes.

L'écran profil entreprise est tout aussi important : raison sociale, GSTIN, adresse enregistrée et paramètres de série de facturation (préfixe, prochain numéro et limites d'année financière). Verrouillez ceci avec des permissions car les changements affectent tous les documents futurs.

Principes de journal d'audit (confiance et traçabilité)

Vous n'avez pas besoin d'un système complexe, mais vous avez besoin d'une piste. Enregistrez qui a changé le HSN/SAC, les taux, les paramètres de série de factures ou le GSTIN de l'entreprise, avec l'ancienne valeur, la nouvelle, l'horodatage et la raison.

Si vous construisez ces écrans dans un outil comme Koder.ai, traitez le logging d'audit et les dates effectives comme des champs de première classe dès le jour 1. Ils coûtent peu à ajouter tôt et font gagner des heures lors des revues financières.

Étape par étape : de la commande à la facture conforme

Une facture conforme tient moins à la mise en forme qu'au gel des bons faits au bon moment. Si vous concevez votre modèle de données facture GST autour de ce flux, le travail financier devient un simple rapprochement, pas une enquête hebdomadaire.

1) Geler ce que le client a réellement acheté

Avant de calculer la taxe, verrouillez un snapshot de la commande : articles, quantités, prix unitaires, remises, frais de livraison, GSTIN client (si présent), adresses de facturation et de livraison, et signaux de lieu d'approvisionnement. Le snapshot ne doit pas changer même si le prix du produit ou le mappage HSN change plus tard.

2) Transformer le snapshot en lignes de facture (avec attributs fiscaux copiés)

Calculez les taxes et générez les lignes de facture à partir du snapshot. Chaque ligne de facture doit copier le HSN/SAC, le(s) taux de taxe, la valeur taxable et les montants de taxe utilisés à ce moment-là, au lieu de les rechercher dynamiquement plus tard.

3) Émettre la facture et la rendre immuable

Assignez le numéro de facture et la date d'émission, puis marquez la facture comme émise. À partir de ce moment, bloquez les modifications de prix, des taux fiscaux, des codes HSN et des adresses sur l'enregistrement de la facture. Si vous devez autoriser quelque chose, limitez-le aux notes non financières et aux tags internes.

4) Produire le document final et stocker les totaux

Générez le PDF/vue impression depuis la facture émise, puis stockez les totaux finaux que vous déclarerez : total taxable, totaux CGST/SGST/IGST, arrondi et montant global. Si vous voulez une sécurité supplémentaire, stockez une version du document ou un checksum pour prouver que l'impression correspond aux nombres stockés.

5) Gérer les changements légalement

Après émission, les changements doivent suivre des règles, pas des éditions :

• Correction de prix demandée par le client : émettre une note de crédit (ou une note de débit) référencée à la facture d'origine.
• Commande annulée après émission : annulez la facture si autorisé, sinon émettez une note de crédit.
• Client met à jour l'adresse après émission : ne réécrivez pas la facture ; corrigez via le document approprié et conservez la trace d'audit.
• Remboursement partiel : note de crédit uniquement pour les lignes/montants remboursés.
• Envoi de remplacement : nouvelle commande/facture, pas une modification silencieuse.

Si vous intégrez ce flux dans vos écrans admin (le mode Planification de Koder.ai est utile pour cartographier les étapes avant de construire), votre équipe pourra générer des factures rapidement sans casser la réconciliation ultérieure.

Rendre la réconciliation simple : paiements, remboursements et registres

La réconciliation devient pénible quand les paiements sont traités comme un simple indicateur payé/non payé sur la commande. Gardez paiements et remboursements comme des enregistrements séparés qui pointent vers la commande et la facture, afin que la finance puisse rapprocher les règlements bancaires sans réécrire l'historique.

Paiements et remboursements séparés (ne pas éditer la facture)

Une facture conforme doit rester stable après émission. Si un client paie en plusieurs fois, ou si vous remboursez plus tard, enregistrez ce mouvement comme une entrée de paiement ou de remboursement, pas comme un changement des totaux de la facture.

Champs minimaux qui facilitent la réconciliation :

• Payment : payment_id, order_id, invoice_id, method, gateway_name, gateway_payment_id, amount, currency, authorized_at, captured_at, settlement_date, status
• Settlement (optionnel mais utile) : settlement_id, gateway_payout_id, settlement_date, gross_amount, fees, net_amount
• Refund : refund_id, order_id, invoice_id, payment_id, credit_note_id (si émise), gateway_refund_id, amount, reason, refunded_at, status
• Clés de réconciliation à ne jamais réutiliser : order_id, invoice_id, payment_id, refund_id, credit_note_id

Si le client retourne un article, ne « réduisez » pas la facture. Émettez une note de crédit et liez-la à la facture d'origine. Le registre des factures reste propre, et le remboursement se rattache à la note de crédit.

Vue finance et exports qui font gagner des heures

Donnez à la finance un écran unique qui répond : qu'est‑ce qui a été émis, qu'est‑ce qui a été payé, qu'est‑ce qui est encore ouvert, et qu'est‑ce qui a été annulé. Incluez un vieillissement (0-7, 8-30, 31-60, 60+ jours) et la possibilité d'explorer les paiements et remboursements liés.

Exports dont la plupart des équipes ont besoin chaque mois :

• Registre des factures (émises, annulées, créditées)
• Synthèse fiscale par taux et HSN/SAC (supporte votre modèle de données GST)
• Rapprochement Paiement vs Facture (invoice_id, totaux paiements, solde)
• Registre des remboursements et notes de crédit
• Rapport de règlement passerelle (mapping payout_id vers invoice/payment)

Exemple : une commande est Rs 10,000, payée Rs 6,000 aujourd'hui et Rs 4,000 la semaine suivante. La facture reste Rs 10,000. Votre vue finance affiche solde Rs 4,000 jusqu'à l'arrivée du second règlement, puis marque comme entièrement payée sans modifier le document émis.

Pièges courants qui causent des problèmes de conformité et de discordance

La plupart des problèmes de facture GST ne sont pas des problèmes de logique fiscale. Ce sont des problèmes de tenue des enregistrements : les chiffres sur le PDF ne correspondent pas à ceux des exports financiers, ou la facture ne peut pas être expliquée des mois plus tard.

Le premier piège est de calculer la GST uniquement au moment de l'affichage. Si vous calculez CGST/SGST/IGST à chaque ouverture d'une facture, vous finirez par obtenir des résultats différents après un changement de taux, un changement d'arrondi ou une correction de bug. Stockez la ventilation fiscale calculée utilisée lors de l'émission, même si vous stockez aussi les entrées.

Un second piège est d'autoriser des modifications sur une facture émise. Une fois la facture finale, les modifications doivent se faire via une note de crédit ou un flux de remplacement avec une piste d'audit. Sinon, vous entendrez « pourquoi le PDF client diffère des livres ? ».

Voici les motifs de discordance qui apparaissent le plus souvent :

• Le lieu d'approvisionnement est manquant ou le code d'état est erroné, donc IGST est appliqué alors qu'il aurait fallu CGST+SGST (ou inversement).
• Le HSN/SAC du produit ou le taux fiscal est mis à jour, et les anciennes commandes sont recalculées avec la nouvelle valeur.
• La taxe est stockée, mais les règles d'arrondi diffèrent entre UI, génération PDF et exports CSV.
• Les remises sont appliquées après taxe à un endroit et avant taxe à un autre.
• Les remboursements sont enregistrés comme lignes négatives sans lien clair avec la facture d'origine.

Un exemple rapide : vous vendez à un client au Karnataka, mais l'adresse de livraison est au Maharashtra. Si votre système prend par erreur l'état de facturation pour le lieu d'approvisionnement, vous pouvez facturer CGST+SGST au lieu d'IGST. Si vous recalculer aussi la taxe à la volée, cette erreur peut se « corriger » silencieusement plus tard, laissant la finance avec des chiffres qui ne correspondent pas au document émis.

Lorsque vous construisez des écrans admin (personnalisés ou via une plateforme comme Koder.ai), ajoutez de petits garde-fous : verrouillez les factures émises, affichez les entrées de lieu d'approvisionnement à côté du type de taxe calculé, et conservez un snapshot immuable du HSN, du taux et de l'arrondi utilisés au moment de l'émission.

Liste de contrôle rapide et prochaines étapes

Avant d'envoyer une facture à un client ou de la marquer comme « émise », exécutez un petit ensemble de vérifications. C'est là que la plupart des petites erreurs deviennent de gros casse‑têtes de réconciliation. Si vous construisez un modèle de données facture GST, il vaut la peine d'intégrer ces contrôles dans les règles de validation et votre UI admin.

Vérifications par facture (avant émission)

• Le HSN/SAC est présent sur chaque ligne et correspond au produit ou service réellement vendu.
• Les règles GSTIN sont appliquées correctement (B2B vs B2C), et les détails de facturation et de livraison ne se contredisent pas.
• Le lieu d'approvisionnement est stocké et la répartition fiscale a du sens (CGST/SGST vs IGST).
• Les totaux s'additionnent exactement : valeur taxable, chaque composante fiscale, arrondi et montant global.
• Une fois émise, la facture est verrouillée (pas d'éditions silencieuses). Les corrections se font via une note de crédit ou un flux d'annulation, pas en réécrivant l'historique.

Un exemple simple : un client met à jour son adresse de livraison après le paiement et l'état change. Si vous réémettez le même numéro de facture avec une nouvelle taxe, votre registre et les enregistrements de paiement cessent de correspondre. L'approche plus sûre est de garder la facture originale immuable et de créer un document d'ajustement.

Vérifications données + workflow (pour garder la finance propre)

• La numérotation des factures est unique, séquentielle selon votre politique et générée uniquement au moment de l'« émission ».
• Stockez les montants fiscaux calculés que vous avez utilisés, pas seulement les taux, pour que les rapports restent stables même si les taux changent plus tard.
• Des étapes de statut claires existent : draft -> issued -> cancelled (et documents de note de crédit séparés).
• Les rapports se rapprochent par période : les totaux du registre des factures doivent correspondre aux paiements capturés, aux remboursements traités et aux créances clients ouvertes.
• Les champs d'audit sont toujours présents : créé par, émis à, et une note de raison pour les annulations ou notes de crédit.

Étapes suivantes : implémentez d'abord les écrans et validations, puis itérez. Dans Koder.ai, commencez en mode Planification pour esquisser les enregistrements et les écrans admin (produits avec mappage HSN/SAC, détails client/GSTIN, règles fiscales et factures). Générez l'application, testez quelques commandes réelles de bout en bout, puis utilisez les snapshots et le rollback pour affiner en toute sécurité le workflow. Quand vous avez besoin de personnalisations plus profondes ou de revues, exportez le code source et continuez à l'évoluer avec votre processus habituel.