Scope before code
Design starts with the legislation, filing instructions and technical specifications. Before development, the included and excluded cases, the sources to be verified and the points at which the tool must stop and request a professional decision must be listed.
Data produced by the ERP
Typical inputs include monthly VAT ledgers, VAT settlements, accounting results, period credits or payables and the full list of tax codes used in the ERP. Formats may be PDF or Excel, but they must be described precisely: columns, signs, total rows, documents to ignore and missing data.
Mapping tax codes to VP fields
Mapping translates the ERP's language into the filing's language. For each tax code, the nature of the transaction, inclusion or exclusion, destination VP field and any conditions are defined. A new or unrecognised code must not be classified automatically without evidence; it must appear among the anomalies.
- Importable and exportable mapping, preserving company-specific memory.
- History of changes and decisions.
- Diagnostics for codes without a rule or with an incomplete rule.
Outputs and reconciliations
The output is not limited to VP1–VP14 fields. It must show how each amount was built, which transactions compose it, which codes were excluded and which differences arise against VAT settlements and accounting records. Only after these controls may an XML file or filing statement be produced.
- Reconciliation between VAT ledgers and monthly settlements.
- Reconciliation with the period's accounting results.
- Drill-down from the VP field to underlying transactions.
- Explicit list of exclusions, exceptions and missing data.
Ordinary tests, edge cases and invalid inputs
Before release, a PASS/FAIL matrix is built. The dataset must include a clean quarter, new tax codes, credit notes, zero amounts, unexpected signs, incomplete files and rare cases. The expected result is defined before seeing the prototype.
Review and project status
The review is performed in a separate conversation supplied with the brief, code and testing matrix. The request is not to confirm the result, but to identify how it might be wrong. Documentation must state limitations, open assumptions, unhandled cases and conditions of use.
This page describes the design method applied to the LIPE Generator, now available in Tax Automation Lab. The tool remains a support instrument: VAT-code classification, VP-framework review and validation of the filing file remain the professional's responsibility.