audit-fiscal-keys

Audit fiscal-document pipelines for 50-digit Hacienda key extraction and XML-root-based document type.

Updated Feb 26, 2026
One-click install
npx skills add https://github.com/ElPoot/contabilidad --skill audit-fiscal-keys
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: audit-fiscal-keys
Source: https://github.com/ElPoot/contabilidad/tree/main/.agents/skills/audit-fiscal-keys
Command: npx skills add https://github.com/ElPoot/contabilidad --skill audit-fiscal-keys

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Prevents misclassification of electronic tax documents by ensuring the 50-digit Hacienda fiscal key is extracted correctly and the document type is derived from the XML root tag, not from the filename.

Core Features & Use Cases

  • Fiscal key integrity auditing: Reviews how the system finds and validates exactly 50-digit Hacienda keys from PDFs, including handling multiple keys (e.g., NC PDFs).
  • XML-driven document typology: Confirms that tipo_documento is determined strictly from the XML root.tag (FacturaElectronica/NotaCreditoElectronica/MensajeHacienda) per the required rules.
  • No-assumption code review: Reports only findings observable by reading the existing implementation in the specified modules.

Use case example: You suspect the classification might be incorrect for Nota de Crédito PDFs that contain multiple keys; this skill audits whether the code uses the last key and whether tipo_documento truly comes from the XML root tag.

Quick Start

Ask the skill to audit the current implementation for Hacienda 50-digit key extraction and XML-root-based tipo_documento derivation, highlighting any violations.

Frequently Asked Questions about audit-fiscal-keys

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify Hacienda fiscal key extraction from a PDF is exactly 50 digits?

To verify Hacienda fiscal key extraction, audit the pipeline to confirm it enforces a strict 50-digit pattern match with exact length validation. This ensures correct key extraction from electronic invoices and prevents document misclassification.

Why does my electronic invoice type show NotaCreditoElectronica when the XML root tag is FacturaElectronica?

Your electronic invoice type may show NotaCreditoElectronica incorrectly if tipo_documento is derived from filename markers like _NC instead of the XML root tag. Document type must be determined strictly from the XML root.tag to avoid misclassification.

How do I handle PDFs containing multiple Hacienda keys for Nota de Crédito documents?

Handling PDFs with multiple Hacienda keys requires auditing the extraction logic to verify which key is selected, such as using the last key. This ensures correct fiscal key integrity for Nota de Crédito documents containing multiple embedded keys.

Can I classify electronic tax documents using filename markers like _respuesta or _NC?

You cannot classify electronic tax documents using filename markers like _respuesta or _NC. Document classification must be derived strictly from the XML root tag, such as FacturaElectronica or MensajeHacienda, to ensure accurate typology.

What is XML root tag document-type determination for Hacienda electronic invoices?

XML root tag document-type determination is the process of deriving tipo_documento strictly from the XML root.tag, distinguishing between FacturaElectronica, NotaCreditoElectronica, and MensajeHacienda, rather than relying on filename assumptions.