SCHEMA-001
XML Not Well-Formed (Parser Error, No Rule ID)
What This Error Means
SCHEMA-001 is not an official rule ID; docutools.pro uses it as a label for files that cannot be parsed as XML at all. The KoSIT validator then stops at the first step: its report shows no scenario and no rule, only a parser message such as 'The entity name must immediately follow the '&' in the entity reference' with line and column, and the file is not accepted (current KoSIT versions word this as 'Das Dokument sollte nicht automatisiert angenommen werden', older ones as a recommendation to reject). Common causes are an unescaped & or < in a text value, a tag that is never closed, wrong nesting, text before the XML declaration, or an encoding declaration that does not match the file.
Why this happens
Well-formedness is the most basic requirement: every start tag has a matching end tag, elements nest correctly, there is exactly one root element, and characters that have a meaning in XML are escaped. If any of this fails, no schema and no Schematron rule can run. The most common real-world cause is a company or product name with an ampersand ('Meyer & Sohn') inserted into the XML by string concatenation instead of an XML library. Others: a truncated file after a failed upload or a size limit in an interface; log output or a PHP warning printed before the XML declaration; two XML documents written into one file; or a file saved as Windows-1252 while declaring UTF-8, which breaks at the first umlaut. A UTF-8 byte order mark (BOM) is accepted by the KoSIT validator, but some upload portals and older parsers reject it, so saving without BOM is the safer choice.
How to Fix It
Open the file in an XML-aware editor, which points to the line and column of the first error, and fix the syntax. Escape special characters in text values: & → &, < → <, > → >, and " → " inside attributes. Save as UTF-8 and make sure the declaration says encoding="UTF-8".
Step-by-step
1) Open the file in an XML-aware editor (for example VS Code with an XML extension, oXygen or XMLSpy); it shows the line and column of the first error. 2) Escape special characters in all text values: & → &, < → <, > → >, and " → " inside attribute values. 3) Check that every opening tag has a matching, correctly nested closing tag and that there is only one root element. 4) Remove anything before <?xml version="1.0" encoding="UTF-8"?>. 5) Save as UTF-8 and make sure the declared encoding matches. 6) Fix the cause in the generator: build the XML with a library that escapes values automatically instead of concatenating strings. 7) Validate again; only a well-formed file reaches the schema and Schematron checks.
<?xml version="1.0" encoding="UTF-8"?> <!-- wrong: <cbc:RegistrationName>Meyer & Sohn GmbH</cbc:RegistrationName> --> <cbc:RegistrationName>Meyer & Sohn GmbH</cbc:RegistrationName>
Fix Automatically
Upload your invoice to our Smart Repair engine. It checks the file against the full KoSIT rule set, including SCHEMA-001, and corrects supported fields with a GoBD audit trail.
Open Smart RepairFrequently asked questions
Why does a company name with '&' break the XML?
Because '&' starts an entity reference in XML. A literal ampersand in text must be written as &, so 'Meyer & Sohn' becomes 'Meyer & Sohn'. The same applies to <.
Is a byte order mark (BOM) a problem?
Not for the KoSIT validator, which accepts a UTF-8 BOM. Some portals and older parsers reject it, though, so save as UTF-8 without BOM to be safe.
Why does the report show no rule ID?
Rule IDs come from the Schematron, which can only run on a parsed document. A parser error happens before that, so there is only the parser message with line and column.
Related Errors
Other commonly encountered validation errors