Why does the tool say my amount is not a number when I typed 120 SAR?

What is accepted and what is refused

We tried a five-row file in the Expense summary generator tool, all with valid dates and the category Ads:

• Row 2, amount «120 ر.س» with currency SAR: refused, 'the amount is not a number'. The same happens with '10 SAR'.
• Row 3, amount '1,250.75' with a thousands separator: accepted and read as 1250.75.
• Row 4, amount «١٢٠٫٥٠» in Arabic-Indic digits with the Arabic decimal mark: accepted and read as 120.50.
• Row 5, amount 80 with currency «ريال» (riyal): refused, 'the currency must be a three-letter code such as SAR'.
• Row 6, amount '(50)' in brackets, the way some accounting software writes negatives: refused, 'the amount is not a number'.

Result: two accepted entries totalling 1,371.25 SAR, and three rows in the not-imported list. Refused rows never reach the totals and are never dropped silently.

Why doesn't the tool just strip 'SAR' itself?

Because a code inside the amount may name a different currency from the currency column. A cell saying '45 AED' on a row whose currency is SAR: which one is right? If the tool ignored the code, it would add dirhams to riyals without knowing. So it asks you to separate the two once, in the file.

Fixing it in Excel

1. Select the amount column, open Find and Replace, search for ' SAR' with the leading space and replace it with nothing. Repeat for any other codes or symbols.
2. In the currency column, replace 'riyal', 'SR' and «ر.س» with SAR. Lower case is fine: sar is read as SAR.
3. Turn brackets into a minus sign if they mean a refund, since the tool reads a negative amount as a refund that lowers the total.
4. Save as CSV UTF-8, import again and check the refused-rows list is now empty.

The European comma trap

Watch for files from systems that write numbers the European way, such as '1.250,75' for one thousand two hundred and fifty and 75 halalas. When a point and a comma both appear, the tool treats the last one as the decimal mark, so this amount is read correctly as 1,250.75. The trap that remains is an amount with only a thousands point, such as '1.250' for one thousand two hundred and fifty: it is read as 1.25, because a lone point is taken as the decimal mark. If a total comes out far smaller than you expect, this is the first thing to look for. Arabic-Indic digits need no conversion, but if you want the whole file in one digit style, convert it with the Arabic/Persian/Western digit converter before saving.