Invoice register cleanup
Normalizes an invoice register, repairs safe formatting inconsistencies, identifies missing keys and duplicate records, and reports changes without inventing financial facts. Use for accounts-payable register cleanup, invoice control, and finance data preparation.
Publicado 21 de ago de 2026 · Actualizado 26 de ago de 2026
Requisitos
Map register, supplier, PO, payment, attachment, and cost-center columns. Define normalization rules for dates, decimals, currencies, supplier IDs, and invoice numbers. Add duplicate keys, status vocabulary, and safe-change policy.
Documento de la habilidad
El SKILL.md completo que tu agente lee y sigue.
Invoice register cleanup
Purpose
Create a controlled, normalized invoice register that preserves original values, exposes duplicate and missing-key risks, and records every safe transformation.
Scope
Handle invoice ID, supplier ID and name, invoice number, invoice date, due date, currency, subtotal, tax, total, purchase order, cost center, status, payment date, attachment ID, and source row. Normalize formats and validate relationships without changing financial meaning.
Excluded: posting invoices, paying suppliers, deleting rows, resolving supplier identity by external research, and recalculating tax.
Data basis
- AP invoice register and source row identifiers.
- Supplier master, purchase-order table, payment table, currency list, and field-mapping rules.
- Prior cleaned register or duplicate-resolution decisions when available.
Result
A cleaned register, change log, duplicate-candidate sheet, and exception summary with raw and normalized values side by side.
Quality criteria
- Row count and source IDs are preserved.
- Numeric totals are not altered by formatting cleanup.
- Duplicate candidates show matching keys and conflicting fields.
- Every changed cell has a rule and original value.
Instructions
Normalize whitespace, case, date format, decimal separators, currency codes, and supplier identifiers only under the mapping rules. Treat invoice number as supplier-scoped, not globally unique. Compare totals arithmetically but do not repair discrepancies. Keep voided, paid, and credit-note statuses explicit and retain credit signs.
A normalization is safe only when it changes representation rather than meaning. Supplier-name cleanup must not collapse two supplier IDs. Report a credit note with its document type and signed amount so control totals remain interpretable.
Keep source-row lineage on every normalized invoice and never use a cleaned field as evidence that an invoice was approved or paid.
Adapt before use
- Map register, supplier, purchase-order, payment, and attachment columns.
- Define date, decimal, currency, supplier-key, and invoice-number normalization rules.
- Add duplicate keys, allowed status values, and the safe-change policy.
Habilidades relacionadas
- Preparar información exógena para la DIAN
Guía a un agente para preparar la información exógena DIAN de un contribuyente colombiano: diagnóstico de obligación, búsqueda de datos en Atlas o archivos del usuario, limpieza de terceros, matriz de formatos, live documents de revisión, tablas listas para prevalidador y paquete final.
- Registrar una factura de compra en Siigo
Guía a un agente para construir el payload completo y registrar una factura de compra (FC) en Siigo a partir de una factura electrónica, resolviendo impuestos, retenciones, pagos, centro de costo y terceros.
- Siigo chart of accounts import
Imports the chart of accounts exported from Siigo Nube into the Siigo chart of accounts record type so posting skills can look up account codes. Use after creating the table from the Siigo integration or whenever accounts change.
- Siigo payment voucher posting
Posts a Recibo de Caja, Comprobante de Egreso or Comprobante contable in Siigo Nube from a described payment, resolving the third party, open invoices, document type and account codes before writing. Use when a payment must be recorded in Siigo with the correct accounts.