I saved my expenses from Excel as CSV and the Arabic categories came out as gibberish or the file was refused. What went wrong?
Save the file again from Excel choosing 'CSV UTF-8 (Comma delimited)' rather than plain 'CSV (Comma delimited)', then import it again. The tool reads UTF-8 only, and when a file arrives in another encoding it refuses it with a clear message rather than show your Arabic categories mangled. Gibberish usually appears on the way back, when you open the downloaded summary in Excel with the BOM option switched off.
Two different problems, in two directions
- On import: a message says the file could not be read as UTF-8. The file was not read at all, and none of its rows reached the totals.
- On export: you downloaded the summary as CSV, opened it in Excel, and categories such as «شحن» and «تغليف» came out as jumbled Latin characters. The file is fine; Excel read it with the wrong encoding.
Each has a different fix, so work out which one you have first.
Fixing the import
Excel on Windows offers two similar options under Save As. The older 'CSV (Comma delimited)' saves Arabic in the legacy Windows Arabic encoding; 'CSV UTF-8' saves it in the encoding the tool understands. The first kind is refused outright, because the Expense summary generator tool rejects any byte that is not valid UTF-8 rather than guess.
- Open your file in Excel as it is.
- Choose Save As, and from the file type list pick 'CSV UTF-8 (Comma delimited)'.
- Import the new file into the tool.
- Check the message under the import area: it should say the entries were read, plus how many rows could not be read, if any.
We tried a file saved this way with Arabic headers, «التاريخ», «التصنيف», «المبلغ», «العملة» and «ملاحظات». The tool matched all five columns on its own with no manual mapping and read two entries, shipping 75.00 and packaging 40.50, for a total of 115.50 SAR.
If you do not have Excel to hand to save it again, you can open the file in the CSV and JSON converter with the Windows-1256 encoding selected, to see whether that really is its encoding.
Fixing the export
Under 'Download the summary' there is an option, 'Add a BOM to the CSV (for Excel)', switched on by default. The BOM is three bytes at the start of the file that tell Excel the text is UTF-8. If you turn it off and then double-click the file, Excel may read it in a legacy encoding and garble the Arabic. Turn the option back on and download again. If the file is going into accounting software that does not expect the mark, switch it off for that system only.
Common questions
Was part of the file refused, or all of it?
An encoding error refuses the whole file. Rows with a bad date, amount or currency are refused on their own and listed by number.
Does the BOM change the numbers in the summary?
No, it only adds a mark at the start of the file; the tables and totals are unchanged.
