HolofinHolofinDocs

HoloLang / Sealed Fields

Verdict fields published by FORMAT validators, and the 2D-Doc sealed fields available on each document type.

Derived Verdict Fields

A 2D-Doc is the Data Matrix printed on French administrative and commercial documents: avis d'impôt, justificatifs de domicile, bulletins de salaire, relevés de compte. It is a cachet électronique visible: the issuer's own copy of the document's key data, signed with a certificate accredited by ANTS (France Titres), so the page can be checked against what its issuer actually emitted. See 2D-Doc seals for what Holofin verifies, and the ANTS 2D-Doc page for the specification itself.

Looked-up data always hangs off the field it came from. A schema field declared with the 2D-Doc type (say cachet) publishes the decoded seal as @enriched.cachet.*; VALIDATE @adresse FORMAT ADDRESS_FR publishes @enriched.adresse.*. Naming the field is what lets one document carry two addresses (a billing one and a delivery one), each with its own verdict.

A 2D-Doc field needs no rule to be decoded and verified. The seal is read on every run, so its paths are available from the first line of a rule and you write a rule only to pin a sealed value against an extracted one. That pin names the exact sealed field it must equal, which is what catches two values swapped between fields.

# No VALIDATE line: `cachet` is a 2D-Doc schema field, decoded on every run.
# Always gate a pin on the signature - an unsealed document has nothing to
# compare, and an ungated pin would fail it.
IF @enriched.cachet.signature_valid == 'true' THEN ASSERT @enriched.cachet.fiscal.declarant_1 == @declarant1
IF @enriched.cachet.signature_valid == 'true' THEN ASSERT @enriched.cachet.adresse_domicile.code_postal == @postcode

# Require the seal to belong to the right kind of document. The same document
# is sealed under a new type code each specification version, so accept the
# whole family and keep the codes quoted.
IF @enriched.cachet.status == 'matched' THEN ASSERT @enriched.cachet.doc_type == '18' OR @enriched.cachet.doc_type == '24' OR @enriched.cachet.doc_type == '27'
Sealed fields, by document type

Which fields a seal carries depends on the document type it was issued for: an avis d'impôt seals declarants and amounts, a justificatif de domicile seals a postal address, a relevé de compte seals an IBAN. Fields under Always are mandatory for that type; a rule pinned to a field under Sometimes is valid but checks nothing on the documents that omit it. Each name below is a path under your 2D-Doc field's sealed content: for a field named cachet, the name fiscal.declarant_1 is written @enriched.cachet.fiscal.declarant_1.

00 (Document émis spécifiquement pour servir de justificatif de domicile.)

Always

adresse_service.code_postal, adresse_service.commune, adresse_service.ligne2, adresse_service.ligne3, adresse_service.ligne4, adresse_service.ligne5, adresse_service.pays

Sometimes

beneficiaire.ligne1, beneficiaire.nom, beneficiaire.prenom, beneficiaire.qualite, co_beneficiaire.ligne1, co_beneficiaire.nom, co_beneficiaire.prenom, co_beneficiaire.present, co_beneficiaire.qualite

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 00 in §6.1, its data ids in §7.3 and §8.3.

01 (Factures de fournisseur d'énergie)

Always

adresse_service.code_postal, adresse_service.ligne4, adresse_service.pays

Sometimes

adresse_facturation.code_postal, adresse_facturation.commune, adresse_facturation.ligne1, adresse_facturation.ligne2, adresse_facturation.ligne3, adresse_facturation.ligne4, adresse_facturation.ligne5, adresse_facturation.pays, adresse_service.commune, adresse_service.ligne2, adresse_service.ligne3, adresse_service.ligne5, beneficiaire.ligne1, beneficiaire.nom, beneficiaire.prenom, beneficiaire.qualite, beneficiaire.telephone, co_beneficiaire.ligne1, co_beneficiaire.nom, co_beneficiaire.prenom, co_beneficiaire.present, co_beneficiaire.qualite, co_facturation.ligne1, co_facturation.nom, co_facturation.prenom, co_facturation.present, co_facturation.qualite, contrat.date_effet, contrat.numero, contrat.souscripteur, facturation.nom, facturation.prenom, facturation.qualite, facturation.telephone, facture.montant_ttc, facture.numero, facture.numero_client

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 01 in §6.1, its data ids in §7.3 and §8.3.

02 (Avis de taxe d'habitation)

Always

adresse_service.code_postal, adresse_service.commune, adresse_service.ligne4, adresse_service.pays

Sometimes

adresse_service.ligne5, beneficiaire.ligne1, beneficiaire.nom, beneficiaire.prenom, beneficiaire.qualite, co_beneficiaire.ligne1, co_beneficiaire.nom, co_beneficiaire.prenom, co_beneficiaire.present, co_beneficiaire.qualite

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 02 in §6.1, its data ids in §7.3 and §8.3.

03 (Relevé d'identité bancaire.)

Always

banque.bic, banque.iban, banque.titulaire

Sometimes

date_expiration

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 03 in §6.1, its data ids in §7.3 and §8.3.

04 (Avis d'impôt sur les Revenus)

Always

fiscal.annee_revenus, fiscal.date_mise_en_recouvrement, fiscal.declarant_1, fiscal.nombre_parts, fiscal.numero_fiscal_1, fiscal.reference_avis

Sometimes

fiscal.declarant_2, fiscal.numero_fiscal_2, fiscal.revenu_fiscal_reference

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 04 in §6.1, its data ids in §7.3 and §8.3.

05 (Relevé d'identité bancaire.)

Always

banque.qxban, banque.titulaire, date_expiration

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 05 in §6.1, its data ids in §7.3 and §8.3.

06 (Bulletin de salaire)

Always

contrat.date_debut, employeur.siret, periode.debut_activite, periode.fin_activite, salaire.cumul_net_imposable, salaire.net_imposable

Sometimes

beneficiaire.ligne1, beneficiaire.nom, beneficiaire.prenom, beneficiaire.qualite, contrat.date_signature, contrat.duree, contrat.type, denomination_sociale, employeur.nom, employeur.prenom, salaire.brut_mois

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 06 in §6.1, its data ids in §7.3 and §8.3.

07 (Titre d'identité)

Always

identite.genre, identite.nationalite, identite.nom_patronymique, identite.numero_piece, identite.prenoms, identite.type_piece, naissance.pays

Sometimes

adresse_domicile.code_postal, adresse_domicile.commune, adresse_domicile.ligne2, adresse_domicile.ligne3, adresse_domicile.ligne4, adresse_domicile.ligne5, adresse_domicile.pays, identite.mrz, identite.nom_usage, identite.prenom, naissance.date, naissance.lieu, titre_sejour.date_debut_validite, titre_sejour.date_fin_validite

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 07 in §6.1, its data ids in §7.3 and §8.3.

08 (MRZ)

Always

identite.mrz

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 08 in §6.1, its data ids in §7.3 and §8.3.

09 (Facture étendue)

Always

adresse_service.code_postal, adresse_service.ligne4, adresse_service.pays

Sometimes

beneficiaire.ligne1, beneficiaire.nom, beneficiaire.prenom, beneficiaire.qualite

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 09 in §6.1, its data ids in §7.3 and §8.3.

10 (Contrat de travail)

Always

contrat.date_signature, employeur.siret, identite.nom_patronymique, identite.prenom, salaire.brut_mois

Sometimes

contrat.date_debut, contrat.duree, contrat.type, denomination_sociale, employeur.nom, employeur.prenom, periode.debut_activite, periode.fin_activite, salaire.cumul_net_imposable, salaire.net_imposable

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 10 in §6.1, its data ids in §7.3 and §8.3.

11 (Relevé de compte)

Always

banque.bic, banque.iban, banque.titulaire, periode.debut, periode.fin, periode.solde_debut

Sometimes

banque.qxban, date_expiration

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 11 in §6.1, its data ids in §7.3 and §8.3.

12 ()

Always

date_de_signature_de_l_acte, identite_de_l_huissier_de_justice, identite_ou_raison_sociale_du_destinataire, intitule_de_l_acte

Sometimes

identite_ou_raison_sociale_de_tiers, identite_ou_raison_sociale_du_demandeur, numero_de_l_acte

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 12 in §6.1, its data ids in §7.3 and §8.3.

13 (Document étranger)

Always

adresse_domicile.code_postal, adresse_domicile.commune, adresse_domicile.ligne4, identite.genre, identite.nationalite, identite.nom_patronymique, identite.nom_usage, identite.prenoms, naissance.date, naissance.lieu, naissance.pays, titre_sejour.autorisation, titre_sejour.date_depot, titre_sejour.numero_demande, titre_sejour.numero_etranger, titre_sejour.type_document

Sometimes

adresse_domicile.ligne2, adresse_domicile.ligne3, adresse_domicile.ligne5, adresse_domicile.pays, identite.numero_piece, identite.prenom, titre_sejour.categorie, titre_sejour.date_debut_validite, titre_sejour.date_fin_validite, titre_sejour.numero_visa

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 13 in §6.1, its data ids in §7.3 and §8.3.

14 (Attestation DICEM)

Always

categorie_du_vehicule, code_postal_ou_code_cedex_de_ay, commune_de_l_adresse_postale_du, denomination_sociale, identite.nom_patronymique, identite.prenoms, ligne_4_de_l_adresse_postale, marque_du_vehicule, naissance.date, naissance.lieu, numero_d_identification, numero_de_serie, numero_de_siret_ou_rna, type_d_engin, type_de_proprietaire

Sometimes

ligne_2_de_l_adresse_postale, ligne_3_de_l_adresse_postale, ligne_5_de_l_adresse_postale, modele

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 14 in §6.1, its data ids in §7.3 and §8.3.

15 (Attestation de décision favorable d'une demande d'autorisation de travail)

Always

contrat.date_debut, contrat.type, declarant.fonction, declarant.nom, declarant.prenom, identite.nationalite, identite.nom_patronymique, identite.prenom, naissance.date, naissance.lieu, titre_sejour.date_depot, titre_sejour.numero_dossier_autorisation

Sometimes

identite.numero_piece, titre_sejour.numero_etranger_autorisation

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 15 in §6.1, its data ids in §7.3 and §8.3.

16 ()

Always

identite.nationalite, identite.nom_patronymique, identite.prenoms, naissance.date, numero_d_usager, orientation_regionale, titre_sejour.date_fin_validite, titre_sejour.numero_etranger, type_de_procedure

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 16 in §6.1, its data ids in §7.3 and §8.3.

17 ()

Always

civilite, date_de_fin_des_droits, identite.prenoms, information_de_la_direction_territoriale, naissance.date, nom, somme_des_montants_verses_au_titre, titre_sejour.numero_etranger

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 17 in §6.1, its data ids in §7.3 and §8.3.

18 (Avis de Situation Déclarative à l'Impôt sur les Revenus)

Always

fiscal.annee_revenus, fiscal.date_declaration, fiscal.declarant_1, fiscal.nombre_parts, fiscal.reference_avis

Sometimes

fiscal.declarant_2, fiscal.numero_fiscal_1, fiscal.numero_fiscal_2, fiscal.revenu_fiscal_reference

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 18 in §6.1, its data ids in §7.3 and §8.3.

19 (Déclarations de dons)

Always

don.date_enregistrement, don.donataire, don.donateurs, don.droits_payes, don.montant, don.reference_enregistrement

Sometimes

cession.montant_taxable

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 19 in §6.1, its data ids in §7.3 and §8.3.

20 (Déclarations de cession de droits sociaux)

Always

cession.cedant, cession.cessionnaire, cession.montant_cession, don.date_enregistrement, don.droits_payes, don.reference_enregistrement

Sometimes

cession.taux

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 20 in §6.1, its data ids in §7.3 and §8.3.

21 (Attestation 2041-ASK)

Always

adresse_declarant.code_postal, adresse_declarant.commune, adresse_declarant.ligne4, declarant.nom_prenoms, fiscal.millesime, fiscal.sip_gestionnaire

Sometimes

contrat.date_debut, employeur.denomination, fiscal.administration_cantonale

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 21 in §6.1, its data ids in §7.3 and §8.3.

22 ()

Always

identite.nationalite, identite.prenoms, naissance.date, naissance.lieu, nom, uuid_document

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 22 in §6.1, its data ids in §7.3 and §8.3.

23 ()

Always

assure_date_de_debut_de_campagne, assure_identifiant, assure_identifiant_enquete_mce, assure_nom_patronymique, contact_indicateur_de_dematerialisation, identite.prenoms, naissance.date, vie_date_emission_certificat, vie_identifiant_du_certificat_d_existence

Sometimes

assure_email, contact_email, smr_date_de_mise_en_concubinage, smr_indicateur_concubinage, smr_indicateur_non_remarie, smr_indicateur_pacs, smr_indicateur_remarie

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 23 in §6.1, its data ids in §7.3 and §8.3.

24 (Avis de Situation Déclarative à l'Impôt sur les Revenus (V2))

Always

fiscal.annee_revenus, fiscal.date_declaration, fiscal.declarant_1, fiscal.impot_revenu_net, fiscal.nombre_parts, fiscal.reference_avis, fiscal.reste_a_payer, fiscal.retenue_a_la_source

Sometimes

fiscal.declarant_2, fiscal.numero_fiscal_1, fiscal.numero_fiscal_2, fiscal.revenu_fiscal_reference

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 24 in §6.1, its data ids in §7.3 and §8.3.

25 (Autorisation de Travail – AES Métier en Tension)

Always

contrat.date_signature, contrat.duree, contrat.type, date_association, declarant.fonction, denomination_sociale, identite.genre, identite.nationalite, identite.nom_patronymique, identite.numero_piece, identite.prenoms, naissance.date, naissance.lieu, naissance.pays, numero_de_siret_ou_rna, salaire.brut_mois, titre_sejour.numero_etranger

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 25 in §6.1, its data ids in §7.3 and §8.3.

26 ()

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 26 in §6.1, its data ids in §7.3 and §8.3.

27 (Avis de Situation Déclarative à l'Impôt sur les Revenus (V3))

Always

fiscal.annee_revenus, fiscal.date_declaration, fiscal.declarant_1, fiscal.declarant_2, fiscal.impot_revenu_net, fiscal.nombre_parts, fiscal.numero_fiscal_1, fiscal.numero_fiscal_2, fiscal.reference_avis

Sometimes

fiscal.reste_a_payer, fiscal.retenue_a_la_source, fiscal.revenu_fiscal_reference

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 27 in §6.1, its data ids in §7.3 and §8.3.

28 (Avis d'impôt sur les Revenus (V2))

Always

fiscal.annee_revenus, fiscal.date_mise_en_recouvrement, fiscal.declarant_1, fiscal.nombre_parts, fiscal.reference_avis

Sometimes

fiscal.declarant_2, fiscal.impot_revenu_net, fiscal.numero_fiscal_1, fiscal.numero_fiscal_2, fiscal.reste_a_payer, fiscal.retenue_a_la_source, fiscal.revenu_fiscal_reference

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type 28 in §6.1, its data ids in §7.3 and §8.3.

A0 (Certificat de qualité de l'air)

Always

carburant, classe_d_emission_polluante, immatriculation_du_vehicule, marque_du_vehicule, nom_commercial_du_vehicule, numero_de_serie_du_vehicule_vin, pays_ayant_emis_l_immatriculation_du, taux_d_emission_de_co2_du

Sometimes

date_de_premiere_immatriculation_du_vehicule

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type A0 in §6.1, its data ids in §7.3 and §8.3.

A1 (Courrier Permis à Points)

Always

civilite, identite.prenoms, n_dossier, naissance.date, nom, type_de_lettre

Sometimes

naissance.lieu

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type A1 in §6.1, its data ids in §7.3 and §8.3.

A2 ()

Always

date_d_expiration_initiale, numero_de_la_carte

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type A2 in §6.1, its data ids in §7.3 and §8.3.

A3 ()

Always

immatriculation_du_vehicule, numero_de_macaron, numero_evtc

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type A3 in §6.1, its data ids in §7.3 and §8.3.

A4 (Certificat de décès)

Always

code_nnc, code_postal_de_la_commune_de, commune_de_deces, date_et_heure_du_deces, identification_du_medecin, mise_en_biere, nom_du_defunt, obstacle_aux_soins_de_conservation, obstacle_medico_legal, prenoms_du_defunt, recherche_de_la_cause_du_deces

Sometimes

date_et_heure_du_constat_de

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type A4 in §6.1, its data ids in §7.3 and §8.3.

A5 ()

Always

date_d_expiration_initiale, numero_de_la_carte_al

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type A5 in §6.1, its data ids in §7.3 and §8.3.

A6 ()

Always

nom_80, numero_de_carte, organisme_de_tutelle, prenoms

Sometimes

numero_de_licence

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type A6 in §6.1, its data ids in §7.3 and §8.3.

A7 (Certificat de qualité de l'air (V2))

Always

carburant, classe_d_emission_polluante, immatriculation_du_vehicule, marque_du_vehicule, motif_de_sur_classement, numero_de_serie_du_vehicule_vin, pays_ayant_emis_l_immatriculation_du

Sometimes

date_de_premiere_immatriculation_du_vehicule, nom_commercial_du_vehicule, taux_d_emission_de_co2_du

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type A7 in §6.1, its data ids in §7.3 and §8.3.

A8 (Certificat de cession électronique)

Always

code_postal_ou_code_cedex_du, commune_du_domicile_de_l_acheteur, date_de_la_signature_du_vendeur, date_de_premiere_immatriculation_du_vehicule, date_et_heure_d_enregistrement_dans, date_et_heure_de_la_cession, immatriculation_du_vehicule, kilometrage, ligne_4_de_la_norme_adresse_c8, n_d_enregistrement, nom_patronymique_de_l_acheteur, nom_patronymique_du_vendeur, numero_de_serie_du_vehicule_vin, prenom_de_l_acheteur, prenom_du_vendeur

Sometimes

genre_de_l_acheteur, genre_du_vendeur

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type A8 in §6.1, its data ids in §7.3 and §8.3.

A9 ()

Always

naissance.date, nom_80, numero_de_permis_de_chasser, prenoms

Sometimes

numero_de_licence

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type A9 in §6.1, its data ids in §7.3 and §8.3.

AA (Arrêtés Permis de conduire)

Always

civilite, date_edition_du_document, identite.prenoms, n_dossier, naissance.date, naissance.lieu, nom, type_d_arretes_permis_de_conduire

Sometimes

date_de_fin_de_sanction, date_de_notification, date_infraction, heure_de_l_infraction, nombre_pages

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type AA in §6.1, its data ids in §7.3 and §8.3.

AB (Relevé d'Information Permis de conduire)

Always

civilite, date_des_donnees_issues_du_sncp, etat_du_permis_de_conduire_du, identite.prenoms, n_dossier, naissance.date, naissance.lieu, nom, nombre_pages, type_de_releve_de_permis_de

Sometimes

categories_presentes_de_permis_de_conduire, siren_du_demandeur_du_document, solde_de_points

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type AB in §6.1, its data ids in §7.3 and §8.3.

AC ()

Always

nom_80, numero_de_carte, numero_de_licence, prenoms

Sometimes

date_d_expiration_initiale

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type AC in §6.1, its data ids in §7.3 and §8.3.

AD (Certificat de réussite à l'Examen du Permis de Conduire (CEPC))

Always

date_de_debut_de_validite, identite.nom_patronymique, identite.prenoms, naissance.date

Sometimes

date_de_fin_de_validite

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type AD in §6.1, its data ids in §7.3 and §8.3.

AE (Certificat de décès V2)

Always

code_postal_de_la_commune_de, commune_de_deces, date_et_heure_du_deces, identifiant_du_certificat, identification_du_medecin, mise_en_biere, nom_du_defunt, obstacle_aux_soins_de_conservation, obstacle_medico_legal, prenoms_du_defunt, recherche_de_la_cause_du_deces

Sometimes

date_et_heure_du_constat_de

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type AE in §6.1, its data ids in §7.3 and §8.3.

B0 (Diplôme)

Always

date_de_naissance, domaine, genre, mention, niveau_du_diplome_selon_la_classification, nom_patronymique, pays_de_naissance, prenom, specialite, type_de_diplome

Sometimes

liste_des_prenoms, numero_ou_code_d_identification_de

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type B0 in §6.1, its data ids in §7.3 and §8.3.

B1 (Attestation de Versement de la Contribution à la Vie Etudiante)

Always

date_de_naissance, liste_des_prenoms, nom_patronymique, numero_de_l_attestation_de_versement, numero_ou_code_d_identification_de

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type B1 in §6.1, its data ids in §7.3 and §8.3.

B2 ()

Always

code_analyse, date_de_naissance_f2, date_et_heure_du_prelevement, genre_f3, liste_des_prenoms_f0, nom_patronymique_f1, resultat_de_l_analyse

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type B2 in §6.1, its data ids in §7.3 and §8.3.

B3 ()

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type B3 in §6.1, its data ids in §7.3 and §8.3.

C1 ()

Always

code_marchandise, date_de_debut_de_validite, date_de_fin_de_validite, duree_de_validite, eori, nom_du_titulaire, reference_rtc

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type C1 in §6.1, its data ids in §7.3 and §8.3.

C2 ()

Always

date_de_decision, duree_de_validite, nombre_de_lignes_articles, numero_de_decision

Sometimes

date_de_naissance_de_l_expediteur, date_de_naissance_du_destinataire, eori_de_l_expediteur, nom_de_l_expediteur, nom_du_destinataire, prenom_de_l_expediteur, prenom_du_destinataire, raison_sociale_de_l_expediteur, tin_de_l_expediteur

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type C2 in §6.1, its data ids in §7.3 and §8.3.

C3 ()

Always

date_de_decision, duree_de_validite, nombre_de_lignes_articles, numero_de_decision

Sometimes

date_de_naissance_de_l_expediteur, date_de_naissance_du_destinataire, eori_de_l_expediteur, nom_de_l_expediteur, nom_du_destinataire, prenom_de_l_expediteur, prenom_du_destinataire, raison_sociale_de_l_expediteur, siren_de_l_expediteur, siret_de_l_expediteur

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type C3 in §6.1, its data ids in §7.3 and §8.3.

C4 ()

Always

date_de_decision, duree_de_validite, nombre_de_lignes_articles, numero_de_decision

Sometimes

date_de_naissance_de_l_expediteur, date_de_naissance_du_destinataire, eori_de_l_expediteur, nom_de_l_expediteur, nom_du_destinataire, prenom_de_l_expediteur, prenom_du_destinataire, raison_sociale_de_l_expediteur, tin_de_l_expediteur

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type C4 in §6.1, its data ids in §7.3 and §8.3.

C5 ()

Always

date_de_decision, date_de_fin_de_validite_de, nombre_de_lignes_articles, numero_de_licence_da

Sometimes

date_de_naissance_du_destinataire, eori_de_l_exportateur, nom_du_destinataire, prenom_du_destinataire, siret_de_l_exportateur

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type C5 in §6.1, its data ids in §7.3 and §8.3.

C6 ()

Always

date_de_decision, duree_de_validite, nombre_de_lignes_articles, numero_de_decision, raison_sociale_de_l_expediteur, siren_de_l_expediteur, siret_de_l_expediteur

Sometimes

eori_de_l_expediteur

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type C6 in §6.1, its data ids in §7.3 and §8.3.

C7 ()

Always

commune_de_l_expediteur, nombre_de_lignes_articles, numero_du_bon_de_livraison, pays_de_l_expediteur, raison_sociale_de_l_expediteur

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type C7 in §6.1, its data ids in §7.3 and §8.3.

C8 ()

Always

nombre_de_lignes_articles, numero_du_bon_de_livraison, pays_de_l_expediteur, raison_sociale_de_l_expediteur, tin_de_l_expediteur

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type C8 in §6.1, its data ids in §7.3 and §8.3.

C9 ()

Always

annee_du_caducee, mode_d_exercice, nom_d_exercice, numero_ordinal, numero_rpps, prenom_d_exercice

Sometimes

mention_specifique

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type C9 in §6.1, its data ids in §7.3 and §8.3.

L1 ()

Always

agent_prophylactique, date_de_naissance_du_patient, fabricant_du_vaccin, liste_des_prenoms_du_patient, nom_de_la_maladie_couverte, nom_du_vaccin, nom_patronymique_du_patient, nombre_de_doses_attendues_pour_un, rang_du_dernier_etat_de_vaccination

Source: ANTS Spécifications Techniques des Codes à Barres 2D-DOC v3.3.2 (§7) + 3.3.7.2 (§6.1, §8): type L1 in §6.1, its data ids in §7.3 and §8.3.

Two consequences for rule writing. A type-04 avis d'impôt seals no address at all, so an address check against one can never match. The numéro fiscal is mandatory on type 04 but optional on type 18, so the same rule is a real check on one and inert on the other. Every decoded id is named from the specification's own dictionary, which is global to the perimeter, so sealed content is named for every type, and a type the presence matrix does not cover still reports @enriched.cachet.doc_type correctly, with structure_complete reported as 'unknown' rather than a misleading 'true'.

Composed convenience fields

One path per fact, whichever way the issuer encoded it. The specification lets an issuer seal a postal address either as one complete string or as one line per data id, and an identity either as discrete name fields or as a single Qualité/Nom/Prénom composite. Both forms are valid, so Holofin fills the gap: a full address and a split name are always readable at the same path, whichever form the document used. A value the issuer actually sealed always wins; Holofin only composes what is missing. computed lists the paths Holofin assembled, comma-separated, and is empty when every value came off the seal itself.

  • <group>.complete is a whole postal address: the specification's own complete-address field when the issuer sealed one, otherwise the group's lines joined in French postal order (lignes 2–5, then code postal and commune). Pin a full extracted address against it, never against a single ligne4.
  • When the signature verifies, the sealed address is also resolved through the national address base and the verdict sits in the same group: <group>.status, <group>.normalized, <group>.ban_id, <group>.granularity and the other address keys, exactly as on an address_fr field. Compare a sealed and an extracted address through them (@enriched.cachet.adresse_domicile.ban_id == @enriched.adresse.ban_id, gated on both status == 'matched') rather than by string equality, which punctuation and abbreviations defeat. These keys are Holofin's and appear in computed.
  • Slashed composite identity lines (for example beneficiaire.ligne1 holding MME/MARTIN/ANNE) also resolve at <group>.qualite, .nom and .prenom. A composite without the / separator is never split, because the part order would be a guess, and discrete name fields sealed by the issuer always win over the split.
Envelope properties

Available on every 2D-Doc field whatever the document type, alongside the sealed content:

  • status: 'matched' (signature verified), 'invalid' (the seal was altered), 'unchecked' (no opinion: unknown certificate or trust-list gap), 'absent' (no seal on the page).
  • signature_valid: the strings 'true', 'false', 'unresolved'.
  • reason, doc_type, doc_type_label, doc_type_family, ca_id, cert_id, emission_date, signature_date.
  • structure_complete ('true' / 'false' / 'unknown') and missing_required, a comma-separated string of the ids the specification mandates for that type and the seal omits. A seal can verify perfectly and still be incomplete; that is what a stripped and re-signed payload looks like.
  • computed, a comma-separated string of the paths Holofin assembled rather than read off the seal (see composed fields above). Empty when every value came from the issuer, so computed == '' asserts that nothing being pinned was reconstructed.
  • Pins are exact comparisons: no WITHIN tolerance is applied.
  • A numeric extracted field compares correctly against the sealed text, so '82269' equals 82269. Punctuation is not normalised, so pin identifiers, amounts, postcodes and dates exactly; pin a full address via <group>.complete and a name via the split .nom / .prenom fields.
  • Some ids seal several values at once (the list of forenames is one field holding CLARA/RACHEL/ELSA), so use IN there rather than ==, which could never pass.
  • Always gate a pin on signature_valid == 'true' or status == 'matched'. A document with no seal, or one whose certificate cannot be resolved, has no sealed values, and an ungated pin would reject it for a mismatch it could not have.
  • A valid signature proves the barcode was not altered since the issuer signed it. It does not prove the document is the most recent one on file.

Photo Capture Fields

A document uploaded as a photo rather than a PDF carries EXIF metadata: when it was taken, by what, and where. Holofin reads it from the original bytes at upload, before the image is converted, and publishes it as flat exif_* fields.

The same names are available at both rule levels, deliberately, so a rule reads the same wherever it is written. A document's own validation rules, on a custom extractor, address them bare (@exif_gps_present). Case rules address them through the document slot (@justificatif_domicile.exif_gps_present), because at that level they are properties of one upload among several.

Multi-page uploads are merged into one namespace by consensus: a field is published when every source image that has a value agrees on it. On disagreement the field is dropped and exif_divergent is set, which is itself evidence of several different cameras inside what is presented as one document.

Check one asymmetry between the levels before you name a schema field exif_software. In a document's own rules the real extracted field wins: the capture fields are injected into the section output the rule is written against, and silently replacing a value the extractor really produced would misreport the document. In case rules the capture field wins and the collision is reported as a warning, because there it sits beside a whole document's aggregated data rather than inside it.

Guard fields (on every document)

Published on every document at both levels, including PDFs that never had EXIF at all. They are always safe to test, which is what makes them usable as the condition of a guarded rule.

FieldMeaningValues
exif_presentThe upload carried EXIF metadata'true' / 'false'
exif_gps_presentA usable GPS position was read'true' / 'false'
exif_divergentSource images disagreed on a value'true' / 'false'
exif_source_countNumber of source images merged'0', '1', '2'…
exif_address_comparablePhoto position and address position are both known and precise enough to measure between'true' / 'false'
Value fields (only when known)

Absent unless the photo actually carried them. A rule that reads one on a document that has none reports a missing field, which fails a blocking rule. This is deliberate: an unguarded rule fails visibly instead of comparing against a default.

FieldMeaningPresent when
exif_latitudeDecimal degrees, south is negativeexif_gps_present == 'true'
exif_longitudeDecimal degrees, west is negativeexif_gps_present == 'true'
enriched.<field>.exif_distance_kmGreat-circle distance from the photo to that address field, in kilometresDocument rules. The field resolved at street level or better, and the photo carried GPS
exif_address_distance_kmGreat-circle distance from the photo to the document's single address, in kilometresexif_address_comparable == 'true'
exif_captured_atCapture timestampThe camera recorded one
exif_camera_makeManufacturerThe camera recorded one
exif_camera_modelModelThe camera recorded one
exif_softwareSoftware that last wrote the fileThe file recorded one
Always guard, and always on a guard field

A case rule fails when a field it references is missing, and that check covers the field inside an IF condition too. So a guard is only worth writing on a field that is always there: guarding on a value field is undecidable on exactly the documents the guard was meant to spare.

# WRONG - exif_camera_make is absent on a PDF, so the condition cannot be
# answered and the rule fails the dossier on every PDF in it
IF @case.documents.justif.exif_camera_make == 'Apple' THEN ASSERT @case.documents.justif.exif_latitude > 41

# RIGHT - exif_gps_present is on every document, so the guard always answers
IF @case.documents.justif.exif_gps_present == 'true' THEN ASSERT @case.documents.justif.exif_latitude > 41

# doc_category is injected on every document too, and is the guard to reach
# for when a slot mixes photos and PDFs
IF @case.documents.justif.doc_category == 'justificatif_domicile' THEN ASSERT @case.documents.justif.exif_divergent == 'false'

# The same rule inside the extractor that produced the document, where the
# fields are addressed bare rather than through a slot
IF @exif_gps_present == 'true' THEN ASSERT @exif_latitude > 41

The guarded form dictates the rule type it can be written in. IF … THEN ASSERT is a whole rule rather than a condition, so it belongs in a consistency rule, at blocking severity. A validity rule or a warning rule wraps its condition in a keyword that takes an expression, and rejects the guarded form outright.

Was the photo taken at the address?

When a document is both a geotagged photo and carries an address that resolved to coordinates, Holofin measures the great-circle distance between the two and publishes it. There are two forms of the answer, and the one to reach for first names the address field the photo is measured against.

In a document's own validation rules, name the field. Every schema property typed Address (FR) is resolved against the French national address database during extraction, and the result is attached as the enrichment sidecar that rules already read as @enriched.<field>.<key>. Where that field was placed precisely enough and the photo carried GPS, its entry also carries exif_distance_km:

ASSERT @enriched.customerAddress.exif_distance_km < 50

Two photos of the same electricity bill, showing 55 RUE DU FAUBOURG SAINT HONORE, 75008 PARIS and differing only in the GPS position embedded in the image, give the rule above:

# photo shot at the address
exif_distance_km = 0.044     -> rule passes

# same bill, photo shot in Marseille
exif_distance_km = 662.887   -> rule fails
                                "Assertion failed: 662.887 < 50.0"

Naming the field is the disambiguation. A payslip schema carrying both a home address and an employer address gets one honest number for each, and the rule says which one it means:

ASSERT @enriched.domicile.exif_distance_km < 5
WARN IF @enriched.employeur.exif_distance_km > 200

Two properties of this form worth stating:

  • Nothing has to be validated first. The sidecar fires on the schema type alone, so no VALIDATE … FORMAT ADDRESS_FR line is needed and there is no way for the rule to sit silently inert because the workflow lacks one.
  • The key is omitted, never null. It is published only on an entry that the geocoder placed at house-number or street level and that has a photo GPS position to measure from. A commune-level hit is the town-centre point, so a distance from it would be misleading rather than merely imprecise, and no number is published. A rule reading an absent key reports a missing field and fails loudly, rather than comparing against a fabricated zero. status is on every sidecar entry and is the natural thing to gate on, but a 'matched' commune-level entry still carries no distance.
The single-address shortcut

For the ordinary schema that declares one address, the flat exif_address_distance_km saves naming it, and it is the only form available to case rules, which see a document's aggregate rather than its schema fields:

IF @case.documents.justif.exif_address_comparable == 'true' THEN ASSERT @case.documents.justif.exif_address_distance_km < 50

What the guard is protecting you from:

  • A commune-level address match is refused. When the reference dataset can only confirm the town, the coordinates it returns are the town centre, not the address. The distance measured from them says how far the photo is from the mairie. That is misleading, not merely imprecise, so no distance is published at all. Only house-number and street matches are comparable.
  • The distance exists only when the guard is 'true'. There is no second way to read a distance nobody vouched for: no coordinates, no address, a PDF upload or a commune-level match all give 'false' and no value.
  • A schema with several addresses publishes nothing here. This key is published only when the locatable addresses on the document agree on one point, because otherwise « the » distance is not defined: picking one field would make the rule's meaning depend on invisible schema ordering, and taking the smallest would answer a weaker question than the one written. Name the field instead. Two fields holding the same address are not a conflict.
  • In a case rule, the address must actually have been looked up. At that level the coordinates come from the @<slot>.enriched.<field>.* paths, which exist only on documents whose extraction runs VALIDATE @<field> FORMAT ADDRESS_FR. Without that rule in the workflow there is nothing to compare against, so the guard is permanently 'false' and the rule silently never fires. Document rules do not have this trap: they measure against the enrichment sidecar, which needs no rule.

exif_address_comparable answers for this key alone. The per-field distances are independent of it, and are published on a multi-address schema where it is 'false'.

Distances are rounded to the metre. Both endpoints are approximate (consumer GPS is accurate to a few metres at best, and a geocoded address is a building-level point), so thresholds belong at the scale of the question being asked (a few hundred metres for « at this address », tens of kilometres for « in this region »), never at the metre.

A large distance is not proof of fraud on its own: photographs of a document are legitimately taken away from the address printed on it. Run this at warning severity unless the product genuinely requires the photo to be taken on site.