How does it work?

Solution: Informational, not an error. Your XML rows had different field orderings. We used the order of the first row as reference. The reconstructed XML is still 100% valid — field order has no semantic meaning for Google, Akeneo, SFCC or Magento.

Solution: Your XML contains tags like <sale_price/> or <upc/> (empty, self-closing). In practice this isn't a problem: WooCommerce, PrestaShop, Magento, Akeneo and other import systems treat a missing field as "do not modify the existing value" — the same behavior as an empty tag. If you want to force a clear on import, put "0" or a space in the cell.

Solution: Your XML holds empty tags that carry only the attribute naming their column, for example ‹custom-attribute attribute-id="badge"/›. Their cell is empty, and an empty cell writes nothing: they won't be in the rebuilt XML. If they were meant to clear a value on import, clear it in the destination tool.

Solution: Without modifications on your end, the reconstructed XML should be structurally identical. If it isn't (element order, missing attributes), contact support with the original file — that's a bug to fix.

Solution: You probably dropped the .excelify.zip as downloaded: a spreadsheet saves data.csv next to the archive, never inside it, so the .zip still holds the original values. The Rebuild page warns you about it. Choose “Separate files” and drop your edited data.csv with skeleton.json.

Solution: The CSV and the skeleton.json you dropped don't come from the same export, which happens quickly when several exports pile up in Downloads (data.csv, data (1).csv…). Take both files from the same bundle. Adding or removing columns is still allowed.

Solution: Reconstruction stops when filled cells can't be written: a column added for a language, a site or a numbered element the original file doesn't have (custom-attribute[seo_url][de-DE], image-group[3]), a working column with a free-form name ("To check"), a value typed on a row of another type (_type column), values with no header (typed next to the table, or under a header that was cleared: “column with no header, column F”), or a column twice whose copies differ (a backup copy: only the leftmost would be written). The page lists the columns and rows. A working column can stay: rebuild anyway. For a new language or site, add it to an element of the original XML, then transform that file again. Keep a single column per name, and a header above every filled column.

Solution: A cell holds a control character (U+0001, U+001B…), invisible in the spreadsheet, often brought by a copy and paste from another program or a web page. XML forbids it: an import would refuse the whole file. The page shows the column, the rows and the character's code. Rebuild anyway to remove them (the rest of the text is kept), or retype these cells. Line breaks pasted from Word or PowerPoint don't stop the rebuild: they are written as line breaks.

Solution: No problem: ExcelifyXML auto-detects encoding (BOM, <?xml encoding="..."?> declaration or the file's content) and converts to UTF-8 before processing. It also reads the declared Central European, Greek, Turkish, Baltic, Cyrillic, Japanese, Chinese and Korean encodings (Windows-1250 to 1258, ISO-8859, Shift_JIS, EUC-JP, GBK, GB18030, Big5, EUC-KR…), under their other names too (latin1, cp1252, cp932, UHC…). Even a file whose first line announces another encoding while it was saved as UTF-8, or announces UTF-8 while it is Windows-1252, is read correctly. A declared encoding ExcelifyXML can't read exactly (Mac Central European, EBCDIC…) is refused without using a credit: save the file as UTF-8.

Solution: The free plan accepts files up to 4 MB; the VIP plan up to 30 MB (secure direct upload, nothing retained). Beyond 30 MB, contact us for a custom Enterprise pipeline. Whatever its size, a file can hold up to 1.5 million XML elements, nested 100 levels deep at most: beyond that, split it into several files.

Solution: Your file holds two XML documents joined end to end (two pages of an export, two concatenated files), while an XML file has a single root element. Transform each part separately, or put them all inside one root element. No credit is used: the file is refused rather than silently leaving out everything after the first root.

Solution: It is accepted when it only refers to an external DTD, for example ‹!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.069/cXML.dtd"›. ExcelifyXML never downloads that DTD: it keeps the line in the skeleton.json file and writes it back in its place in the rebuilt XML. A declaration that defines entities or elements itself, between brackets [ … ], is refused for the service's security, without using a credit: remove it, then put it back in the rebuilt XML. If it defines entities the file uses (&name;), first replace each one with the character itself or its numeric reference: without the declaration, they would be kept as text. Entities only the DTD defines (&nbsp;, &eacute;…) are refused too, with their line: replace them with their numeric reference (&#160;, &#233;) or with the character itself. Apple property lists (plist files) are still refused, without using a credit: each key is tied to its value only by their order, which the CSV doesn't keep.

Solution: Your spreadsheet expects the other separator (French Excel = semicolon, English = comma). Pick the right one under “Advanced options”, below the preview on the Upload page, or fix the open file via Data → Text to Columns → Delimited in Excel. Reconstruction finds the separator on its own, whatever it is.

Solution: Some tags in your XML contain text interleaved with other tags (e.g. ‹string›Tap ‹b›here‹/b› to continue‹/string›). A CSV can't represent that mix: nested tags (here "b") become columns, but the surrounding text ("Tap", "to continue") is not captured and will be missing from the rebuilt XML. Edit those particular values directly in the original XML file; every other row can be edited in the CSV as usual.

Solution: Your file holds several lists (for instance several SFCC price books or warehouses) and the chosen rows don't say which list they belong to: the rebuilt XML would mix them up. Transform each list as a separate file: you keep one row per price or per product. You can also choose, in the preview, under “Not the right row?”, the element that groups each list (for instance pricebook): each list then becomes a single row of numbered columns, which soon goes beyond the 16,384 columns Excel keeps (the preview says so). No credit is used in that case.

Solution: Excel's classic “CSV” format (like LibreOffice on Windows or Excel on the web) can't write every character: Arabic, Chinese, Greek, Cyrillic… become “?” when the file is saved, and even accents when the computer is set to another language (Polish, Greek, Japanese…). At reconstruction, ExcelifyXML compares the file's “?” with those of your original XML and stops when characters were replaced. It doesn't catch them all: a word typed in another alphabet becomes “????”, a lone accent in a very small file goes unnoticed. The safest: save as “CSV UTF-8 (Comma delimited)” (Excel on Windows) or “CSV UTF-8” (Excel for Mac); Google Sheets and Numbers already save in UTF-8. Other encodings (Mac Roman, Windows in another language) are recognized automatically.

Solution: Opened by double-click, a CSV is read by Excel as numbers and dates: “00123” becomes “123”, an EAN becomes “3.61235E+12” (its last digits are lost), “1-2” becomes “2-Jan”. Open the CSV with Data › From Text/CSV instead, then “Transform Data”, giving these columns the Text type. The transformation screen names the columns at stake, and the reconstruction stops if a code turned into scientific notation, a date appeared in a column that had none or a date changed format (“2026-09-01” became “9/1/2026”).

Solution: A spreadsheet keeps a limited number of columns: 16,384 in Excel and LibreOffice, 1,000 in Numbers. Excel also keeps 32,767 characters per cell at most (Google Sheets 50,000). Whatever goes beyond is cut as soon as the CSV is opened, even without any change: a product with thousands of variants, several warehouses or price lists in numbered columns, a very long HTML description. The preview and the transformation screen point it out, and the reconstruction stops if the CSV comes back cut; “Rebuild anyway” writes the XML without what was cut. Too many columns: in the preview, under “Not the right row?”, choose a row tag that gives narrower rows (for instance variant rather than product), or split the XML file (one list per file). Values too long: edit them in the original XML file rather than in the spreadsheet.