QuickBooks Rejects Em Dashes and Special Characters in XML Imports

Developers integrating third-party applications with QuickBooks Desktop through the Web Connector are running into a stubborn parsing error when customer records contain em dashes, accented letters, or other special characters. The XML may pass standard validation, yet QuickBooks still rejects the payload — leaving imports stalled and troubleshooting frustrating.

The Problem

The issue surfaces most often when pushing customer data into QuickBooks Enterprise using the PHP development kit. A typical scenario involves an address or company name that contains an em dash — the long horizontal punctuation mark commonly used to separate clauses or suite numbers. For instance, a customer record might include a string like “100 W. Randolph – Ste. 4-100,” where the dash between the street name and suite number is an em dash rather than a standard hyphen.

When that record is submitted through the devkit, QuickBooks responds with a generic but final-sounding error: it found a problem parsing the provided XML text stream. The message offers no detail about which character caused the failure or how to fix it, which sends developers down a rabbit hole of trial and error.

What makes this particularly confusing is that the same string typed directly into QuickBooks Enterprise — in this case, the 2019 version — is accepted without complaint. The XML itself also passes validation through standard tools. So on both ends, the data looks clean. Only the trip through the Web Connector breaks it.

Why It Happens

QuickBooks Desktop uses its own XML parser, and that parser is stricter than many general-purpose XML validators. A standard validator may look at an em dash or an accented character like the “é” in “Décor” and see perfectly legal XML. QuickBooks, however, can choke on these characters during the transfer even when the surrounding XML structure is well-formed.

The core issue is that certain Unicode characters — em dashes, en dashes, accented vowels, and similar symbols — need special handling before they can travel through the QuickBooks XML pipeline. Simply dropping them into a name field between opening and closing tags is not enough, even if the result technically qualifies as valid XML by industry standards.

What Actually Works

Community members have identified two reliable approaches, both rooted in standard XML techniques.

Wrap Problem Fields in CDATA Sections

The accepted solution is to wrap any field containing special characters inside CDATA tags. CDATA — short for “character data” — is an XML construct that tells the parser to treat everything between its opening and closing markers as literal text. The parser skips over the content rather than trying to interpret individual characters.

In practice, instead of submitting a customer name as plain text between tags, the field is wrapped so the parser sees the special characters as raw data. This approach is versatile because it handles a wide range of characters — em dashes, accented letters, symbols — without needing to identify or convert each one individually.

For developers using XMLWriter libraries, most implementations include dedicated functions for creating CDATA sections, making this straightforward to implement programmatically.

Encode Characters as Numeric Entities

A second approach is to replace special characters with their numeric XML entity equivalents before sending. For example, the accented “é” in “Décor” would be replaced with its decimal entity reference, turning the visible character into a coded sequence that the parser interprets correctly.

This method requires identifying each problematic character and substituting its corresponding entity code. For developers working with the PHP devkit specifically, a built-in casting function can automate this conversion — it takes the target operation type, the field name, and the raw value, then returns an encoded string safe for transmission.

Which Approach to Choose

CDATA wrapping is generally the more practical option when dealing with unpredictable input, because it does not require knowing in advance which characters need encoding. Any field that might contain em dashes, accents, or other symbols gets wrapped, and the parser handles the rest.

Numeric entity encoding offers more granular control and may be preferable when working with a known, limited set of special characters. The devkit’s casting function makes this largely automatic for supported fields.

Either way, the key takeaway is that standard XML validation alone is not a reliable predictor of whether QuickBooks will accept the data. The QuickBooks parser has its own tolerance level, and developers who account for that up front can avoid the parsing-error loop entirely.