encoding.declaration
XML encoding declaration (Windows-1252)
AT requires Windows-1252 encoding. UTF-8 declarations are silently rejected.
What AT requires
SAF-T (PT) files must declare and use the Windows-1252 (CP-1252) character encoding. Both the XML prolog declaration and the actual byte content must match.
<?xml version="1.0" encoding="Windows-1252"?>
Why files fail
Foreign ERPs and modern tooling default to UTF-8. The XML they produce is well-formed; the schema validates; the file passes most validators. But AT silently rejects it on intake without a useful error message.
The mismatch happens in two flavours:
- Declaration says UTF-8 + bytes are UTF-8 — the entire file is wrong from AT's perspective.
- Declaration says Windows-1252 + bytes are still UTF-8 — happens when someone hand-edits only the prolog. Accented characters then render as garbage when AT decodes them.
How to fix
- Transcode the file body from UTF-8 to Windows-1252.
- Update the XML declaration to match:
encoding="Windows-1252".
Order matters — change the declaration alone and you ship garbage; change the bytes alone and the parser refuses the declared encoding.
Auto-fix
SAFTCheck performs both steps in one click. The fixed file you download has the same data, transcoded byte-for-byte, with the prolog rewritten. Accented characters (ç, ã, é, ó) become single bytes in the 0xA0–0xFF range as AT's tooling expects.
Verifying the fix
On Linux/macOS, file my.xml should report something like "Non-ISO extended-ASCII text" or "ISO-8859 text", not "UTF-8 Unicode". In a hex editor, every accented byte should be a single 0xA0–0xFF byte, not a 0xC3 prefix sequence.
Related
- BOM at file start — the other silent encoding rejection.
- Walkthrough: how to fix the SAF-T UTF-8 encoding error in Portugal