From SAF-T 1.30 to 1.40.
Treat the change as a versioned export migration: update the complete source bundle, regenerate test data and pin expected validation behaviour in CI.
Saftlint understands both profiles: 1.30 is checked against the historical 1.30 XSD, while 1.40 is checked against the 1.40 XSD and the complete content ruleset. Old and new fixtures can therefore remain separate without applying the wrong schema.
Migration checklist
- Read the implementation documentation, technical description and XSD together.
- Set and test AuditFileVersion explicitly.
- Version the XSD, code lists and mapping data as one bundle.
- Regenerate representative fixtures from your product.
- Test references, totals, balance and periods—not only schema validity.
- Keep separate regression coverage for old format versions and accounting years.
Try the same fixture against both profiles
saftlint validate old-1.30.xml
saftlint validate --profile 1.40 old-1.30.xmlThe second run treats 1.40 as the target profile and reports structural and semantic differences, including metadata that still identifies 1.30. Saftlint explains the findings; it does not rewrite the accounting file.