Factures et DeepSeek : vérifier les calculs avec Python

Vérifier chaque ligne avant de demander une explication à DeepSeek

Une facture événementielle peut présenter une somme cohérente et rester incorrecte. Dans l’exemple ci-dessous, les trois montants de ligne du fournisseur totalisent $234.00, exactement comme le total déclaré. Pourtant, une ligne facture $80.00 pour deux unités à $45.00 chacune. La multiplication quantité-prix unitaire donne $90.00 et porte le total calculé indépendamment à $244.00. L’accord entre deux totaux recopiés ne constitue pas une vérification indépendante.

Ce guide fournit à la personne qui coordonne un événement un vérificateur Python exécutable pour détecter cet écart avant de préparer une demande à DeepSeek V4.1 Flash. Il produit un rapport d’anomalies indiquant la ligne concernée et une petite fiche de rédaction que le programme refuse de créer tant que les calculs ne sont pas cohérents. Tous les exemples sont des frais de conférence fictifs ; les résultats proviennent de l’exécution locale du programme. Aucun modèle n’a généré ni approuvé une facture ici.

DeepSeek peut constituer une étape facultative de rédaction après résolution de l’écart par une personne. Il ne doit pas décider du prix convenu avec le fournisseur, autoriser un paiement ou remplacer discrètement une facture. Le document original, le contrat et la clarification restent les preuves à utiliser pour cette décision. Une multiplication correcte établit une relation arithmétique, pas la réalisation d’une prestation ni l’autorisation d’un montant.

L’écart de $10 masqué par un total concordant

L’export fictif contient des badges, de la signalétique de salle et une prestation de sous-titrage. Les quantités représentent des unités entières de prestation. Le vérificateur impose le même schéma à cinq colonnes à chaque ligne et reçoit séparément le total de la facture. Cette valeur séparée compte : comparer la somme à elle-même créerait une nouvelle vérification rassurante mais inutile.

Faites défiler horizontalement pour voir tout le tableau.

Cela ne signifie pas automatiquement qu’il manque $10 à payer. Le fournisseur voulait peut-être appliquer une remise sur cette ligne, ou la quantité ou le prix unitaire sont peut-être erronés. Le programme ne peut pas choisir entre ces explications. Son constat est plus précis : L3 ne satisfait pas la règle annoncée quantité multipliée par prix unitaire. Il faut donc clarifier la facture avant que ce flux crée une fiche de rédaction ordinaire.

Conservez les deux versions si le fournisseur corrige l’export. Le jeu corrigé utilisé plus loin remplace simultanément L3 par USD 90.00 et le total par USD 244.00. Cette réparation a été construite pour tester le programme ; elle ne décrit pas l’intention d’un fournisseur réel. Pour une véritable facture, il faut toujours disposer de la correction effectivement approuvée.

Définir le format monétaire sans deviner la convention locale

Le code accepte des montants USD positifs ou nuls, avec exactement deux décimales, et des quantités entières strictement positives. Il convertit les chaînes monétaires en cents entiers, puis effectue des multiplications et additions entières. Aucune comparaison en virgule flottante binaire ni tolérance ne peut masquer un écart d’un cent. Ce contrat d’entrée est volontairement limité : ce n’est pas un analyseur universel de factures.

Les valeurs telles que 2.500, -2.50, 234,00 et la notation scientifique sont refusées. Les espaces avant ou après les champs numériques le sont également. Un export européen n’est pas incorrect parce qu’il suit une autre convention ; il exige une normalisation distincte, vérifiée avant de passer dans ce contrôleur. Ne devinez pas si un séparateur indique des décimales ou des milliers.

La documentation CSV de Python explique que séparateurs et conventions de guillemets varient. Le programme utilise l’analyseur CSV plutôt qu’un découpage des lignes sur les virgules, et ouvre son flux en mémoire avec la gestion des retours à la ligne de la documentation. Une description entre guillemets contenant une virgule peut ainsi rester un champ unique. Les colonnes inattendues et identifiants de ligne dupliqués sont refusés, sans être ignorés silencieusement.

Quantités fractionnaires, taxes, remises, transport, devises multiples et avoirs sont hors de ce contrat. Si une facture en contient, arrêtez-vous et définissez les règles de calcul correspondantes avant d’utiliser le résultat. Supprimer les lignes non prises en charge pour obtenir un statut valide annulerait l’intérêt du rapprochement.

Exécuter le vérificateur complet en local

Enregistrez le code suivant dans check_invoice.py, puis lancez python3 check_invoice.py. Il utilise la bibliothèque standard de Python, sans API Key ni requête réseau. Les données d’essai et assertions font partie du livrable : vous pouvez reproduire l’écart masqué et le cas corrigé sans acheter d’appel à un modèle.

"""Offline synthetic invoice check. No model/API request; USD integer cents only."""
import csv
import io
import json
import re

HEADER = ['line_id', 'description', 'qty', 'unit_usd', 'line_usd']
CSV = '''line_id,description,qty,unit_usd,line_usd
L1,Name badges,40,2.50,100.00
L2,Room signage,3,18.00,54.00
L3,Captioning service,2,45.00,80.00
'''

def cents(value):
    if not isinstance(value, str) or not re.fullmatch(r'[0-9]+\.[0-9]{2}', value):
        raise ValueError('Use unsigned USD amounts with exactly two decimals')
    whole, fraction = value.split('.')
    return int(whole) * 100 + int(fraction)

def check(text, invoice_total):
    reader = csv.reader(io.StringIO(text, newline=''), strict=True)
    if next(reader, None) != HEADER:
        raise ValueError('Unexpected CSV header')
    seen, rows, issues = set(), [], []
    for fields in reader:
        if len(fields) != len(HEADER):
            raise ValueError('Unexpected column count')
        ident, description, quantity, unit, quoted = fields
        if not ident or ident in seen or not description.strip():
            raise ValueError('Missing or duplicate line identity')
        if not re.fullmatch(r'[0-9]+', quantity) or int(quantity) < 1:
            raise ValueError('Quantity must be a positive whole number')
        seen.add(ident)
        expected, stated = int(quantity) * cents(unit), cents(quoted)
        rows.append(dict(line_id=ident, expected_cents=expected, stated_cents=stated))
        if expected != stated:
            issues.append(dict(line_id=ident, expected_cents=expected, stated_cents=stated))
    if not rows:
        raise ValueError('No invoice lines')
    declared = cents(invoice_total)
    expected_total = sum(x['expected_cents'] for x in rows)
    stated_sum = sum(x['stated_cents'] for x in rows)
    return dict(currency='USD', line_count=len(rows), line_issues=issues,
                expected_total_cents=expected_total, stated_line_sum_cents=stated_sum,
                declared_total_cents=declared, declared_matches_lines=declared == stated_sum,
                eligible_for_draft=not issues and declared == expected_total)

def draft_brief(report):
    if not report['eligible_for_draft']:
        raise ValueError('Resolve arithmetic before creating a drafting brief')
    return {k: report[k] for k in ['currency', 'line_count', 'expected_total_cents']}

def planned_microcredits(inputs, outputs, rate_in, rate_out):
    if any(type(x) is not int or x < 0 for x in [inputs, outputs, rate_in, rate_out]):
        raise ValueError('Planning quantities and rates must be nonnegative integers')
    numerator = inputs * rate_in + outputs * rate_out
    return (numerator + 999999) // 1000000

if __name__ == '__main__':
    bad = check(CSV, '234.00')
    assert bad['declared_matches_lines'] and not bad['eligible_for_draft']
    assert bad['expected_total_cents'] - bad['declared_total_cents'] == 1000
    try:
        draft_brief(bad)
    except ValueError:
        pass
    else:
        raise AssertionError('Bad invoice became a drafting brief')
    fixed = check(CSV.replace('45.00,80.00', '45.00,90.00'), '244.00')
    assert draft_brief(fixed) == dict(currency='USD', line_count=3, expected_total_cents=24400)
    rejected = 0
    for text, total in [
        (CSV.replace('L2,', 'L1,'), '234.00'),
        (CSV.replace(',40,', ',0,'), '234.00'),
        (CSV.replace(',40,', ',1e2,'), '234.00'),
        (CSV.replace('2.50', '2.500'), '234.00'),
        (CSV.replace('2.50', '-2.50'), '234.00'),
        (CSV.replace('L1,Name badges,', 'L1,Name badges,EXTRA,'), '234.00'),
        (CSV, '234,00'),
    ]:
        try:
            check(text, total)
        except ValueError:
            rejected += 1
        else:
            raise AssertionError('Invalid fixture accepted')
    rates = {'catalog_low': (18333360, 73333440), 'catalog_high': (36666720, 146666880)}
    plans = {key: planned_microcredits(1000, 300, *value) for key, value in rates.items()}
    assert plans == {'catalog_low': 40334, 'catalog_high': 80667}
    print(json.dumps(dict(bad=bad, corrected_brief=draft_brief(fixed),
                         negative_fixtures_rejected=rejected, planned_microcredits=plans), indent=2))

Le script renvoie volontairement un rapport pour les écarts arithmétiques, mais lève une erreur pour les entrées mal formées. Ce sont deux situations distinctes : une facture compréhensible peut comporter un désaccord à examiner, tandis que des lignes mal formées ne peuvent pas être interprétées de façon fiable selon le contrat défini. Un import de production devrait aussi comporter des limites de taille, contrôles d’accès, conventions comptables et procédures de revue adaptés à son environnement.

Lire le rapport sans en faire une décision de paiement

Le résultat exécuté contient declared_matches_lines: true et eligible_for_draft: false. Le total attendu vaut 24 400 cents, tandis que le total déclaré et la somme des lignes indiquées valent chacun 23 400 cents. L’anomalie désigne L3, avec 8 000 cents indiqués contre 9 000 attendus. Ces valeurs précises, plutôt qu’un avertissement générique, expliquent le blocage d’un total apparemment cohérent.

Le programme a aussi tenté de créer une fiche à partir du rapport incorrect et a confirmé le refus de la fonction. Avec le jeu explicitement corrigé, il a renvoyé {"currency":"USD","line_count":3,"expected_total_cents":24400}. Cet objet compact constitue le transfert local réussi. Ce n’est ni une réponse de modèle, ni une preuve de conformité fiscale, ni une autorisation de payer USD 244.00.

Sept cas négatifs ont réellement été refusés : identifiant dupliqué, quantité nulle, quantité en notation exponentielle, précision monétaire excessive, prix unitaire négatif, colonne supplémentaire et total à virgule décimale. Cette couverture vise le contrat de l’exemple ; elle ne prouve pas que tous les exports fournisseurs sont sûrs. Les erreurs de syntaxe CSV peuvent aussi interrompre l’analyse. Le script ne prétend pas récupérer automatiquement n’importe quel fichier endommagé.

Donner à DeepSeek une tâche résolue et une limite explicite

Une fois l’écart résolu par le fournisseur ou la personne responsable, la coordination peut demander à DeepSeek un accusé de réception neutre fondé uniquement sur les faits approuvés. Par exemple : « Rédige un bref accusé de réception de la facture USD corrigée à trois lignes, avec un total rapproché de 244.00. N’indique pas que le paiement est approuvé ou programmé. Demande à la personne chargée de la revue de confirmer le numéro de référence avant envoi. » Cette demande n’a pas été exécutée ici.

Le formulaire Orux actuel expose messages, max_tokens et une option de réponse sous forme d’objet JSON pour deepseek-v4.1-flash. Cela vérifie la présence des contrôles, pas la réussite de cette tâche de rédaction. Utilisez l’alias Orux exact de la page du modèle. Le nom utilisé sur le service propre de DeepSeek est un identifiant d’un autre service ; ne le recopiez pas en supposant qu’il s’agit d’un alias Orux.

La référence Chat Completions de DeepSeek documente les données d’usage. Pour une demande exécutée, comptez l’usage effectivement renvoyé : ni les caractères CSV ni le nombre de lignes ne déterminent la consommation de tokens. Si vous attendez un objet JSON, validez ensuite ses champs et valeurs. Une option du formulaire ou une réponse à l’allure convenable ne remplace pas ce contrôle.

En complément, le cas JSON du musée étudie la validation des sorties, tandis que le guide de synthèse du support prépare un autre type d’entrée restreinte. Ce flux de facture apporte un rapprochement arithmétique, sans répéter leurs vérifications d’extraction ou de confidentialité.

Comparer les deux lignes de tarifs Orux publiées

Le catalogue public du 2 novembre 2026 contient deux lignes dailytimeband pour cet alias. Le tableau emploie uniquement les tarifs d’entrée sans cache et de sortie. Il ne suppose pas qu’une facture répétée bénéficiera du cache, et ne déduit pas de l’heure la tranche applicable au compte. Confirmez le devis actuel et les conditions avant d’autoriser une demande.

Faites défiler horizontalement pour voir tout le tableau.

La dernière colonne est un calcul prévisionnel, pas un usage mesuré ni une facture promise. Le programme arrondit chaque demande prévue au micro-Credit entier supérieur. Mille demandes utilisant exactement ces quantités représenteraient donc 40.334 ou 80.667 Credits selon cette convention. L’usage réel, les conditions ou des tentatives supplémentaires modifient le résultat. Aucun débit de compte n’a été mesuré pour cet article.

La page de tarifs du fournisseur décrit ses propres versions et horaires. Ces conditions n’établissent ni le calendrier Orux ni le devis d’un compte. Nous ne prétendons pas que ce flux dépasse la précision d’un autre modèle sur les factures, ni qu’un service coûte moins cher dans toutes les situations. Le calculateur rend un plan explicite vérifiable avant une demande facultative.

Conserver rapprochement, rédaction et approbation séparément

Gardez le CSV original, son total déclaré, le rapport d’anomalies et la correction approuvée. Relancez le vérificateur sur les données corrigées, puis enregistrez la fiche exacte transmise à l’étape facultative du modèle. Vous préservez ainsi la différence entre ce qu’a écrit le fournisseur, ce qu’a calculé le programme et ce qu’une personne a approuvé. Un accusé de réception généré ne doit écraser aucun de ces documents.

Si la rédaction ajoute une date de paiement, des coordonnées bancaires, une référence ou une approbation non autorisées, refusez cet ajout et faites-le résoudre par la personne responsable. Ce guide ne présente aucun texte généré et ne prétend pas qu’un prompt particulier empêche ces ajouts. Son apport terminé est le contrôle arithmétique local et les preuves reproductibles, prêts pour une étape de communication examinée séparément.

Prix et formulaire vérifiés le 2026-11-02. Sources : modèle Orux, catalogue public, CSV Python, types numériques Python, référence DeepSeek, tarifs DeepSeek.

FAQ

Q.Un total concordant prouve-t-il que chaque ligne est correcte ?

Non. Le total démontré correspond aux lignes indiquées alors que L3 échoue au calcul quantité-prix unitaire. Comparez les montants calculés indépendamment pour chaque ligne, ainsi que le total général. Le programme identifie cette contradiction précise ; une personne doit ensuite déterminer quelle valeur source corriger.

Q.DeepSeek a-t-il trouvé l’écart de USD 10 ?

Non. Le programme Python local l’a trouvé et aucun modèle n’a été appelé. DeepSeek reste une étape facultative ultérieure de rédaction, avec les contrôles Orux actuels vérifiés et des tarifs prévisionnels datés. L’article n’évalue ni sa précision sur les factures, ni sa qualité, sa latence ou sa fiabilité.

Q.Puis-je l’utiliser pour les taxes ou plusieurs devises ?

Pas avec le contrat actuel. Il couvre des quantités entières strictement positives et des montants USD sans signe à deux décimales, sans logique fiscale, de remise ou de change. Étendez et testez explicitement ces règles selon la spécification comptable approuvée applicable, plutôt que supprimer des lignes gênantes ou deviner la convention locale.

Q.Les Credits indiqués sont-ils le prix de vérification du CSV ?

Non. Exécuter le contrôleur local ne fait aucune demande Orux et ne consomme aucun Credit du site. Le tableau estime une demande ultérieure facultative avec des quantités de tokens supposées. L’usage réel du modèle et le devis actuel applicable déterminent sa facturation, pas le nombre de lignes CSV.

Q.Que vérifier avant d’envoyer un accusé de réception généré ?

Comparez-le à la correction approuvée et à l’autorité réelle permettant cette communication. Un total rapproché n’autorise ni paiement ni date de paiement. Gardez le rapport source séparé, refusez les détails non étayés et confirmez référence et destinataire avant tout envoi.