FA(3) structured invoice: what it must contain
An overview of critical fields and the most common errors that cause the system to reject the document.
Mandatory data and validations
The FA(3) schema contains fields that must be logically consistent, not just formally consistent. Even technically correct values can be rejected if the relationships between fields are inconsistent.
Therefore, it is worth implementing a two-stage control: technical validation of the scheme and business validation of internal rules.
- •XML structure validation.
- •Validation of the relationship between amounts and rates.
- •Validation of contractor data.
The most common mistakes in practice
Most errors occur with corrections, advance payment documents and unusual sales scenarios. The reason may be the lack of a consistent data model between systems.
Implementing regression tests on representative invoice samples significantly reduces the number of rejections after production starts.
- •Contractor ID errors.
- •Net value and VAT inconsistencies.
- •Problems with correction documents.
How to prepare your company for structure changes
Schemes and interpretations may change, so it is not worth coding the rules rigidly in many places. Better to maintain a central validation module.
This approach speeds up updates and avoids situations where different company systems use different versions of rules.
- •Central validation rules module.
- •Versioning changes in the invoice model.
- •Automatic tests after each update.