## TL;DR

The CSV was written in a legacy encoding (often Windows-1252) where the currency symbol is a byte the importer does not expect, so the import chokes. Re-save the file as UTF-8 (and strip any byte-order mark if the importer dislikes it), then import again. Encoding mismatches are a file problem, not a data problem.

## Error

```text
agent's rightsizing csv import into the finops tool failed  -  encoding error on the currency symbol
```

## Steps

1. Confirm the encoding error: the import log points at the currency symbol column. Expected: the failing character is identified.
2. Check the file's actual encoding. Expected: it shows as Windows-1252 or similar, not UTF-8.
3. Convert the file to UTF-8. Expected: the currency symbols render correctly in the converted file.
4. If the importer rejects the byte-order mark, save as UTF-8 without BOM. Expected: the file has no BOM bytes.
5. Re-run the import. Expected: the rightsizing data loads cleanly.

## When to use

- A CSV import fails with an encoding error on currency symbols.
- The file came from a Windows tool or Excel export.
- Special characters break an otherwise valid import.

## When not to use

- The import fails on column mapping (a schema problem).
- The currency values themselves are wrong (a data problem).
- The file is not a CSV at all.

## Tool compatibility

Applies to FinOps tools with CSV import (CloudHealth, Cloudability, custom tools; current 2026 releases).

### Variant phrasings

### "invalid byte sequence" on csv import

The file encoding does not match the importer's expectation. Convert to UTF-8.

### euro or pound symbol breaks the import

Legacy encodings mangle non-ASCII symbols. Normalize the file.

### excel csv won't import into the finops tool

Excel exports Windows-1252 by default. Re-save as UTF-8.

## Why it happens

CSV has no encoding metadata: the importer guesses, usually UTF-8, while Windows tools write Windows-1252. Currency symbols (euro, pound) live at different byte values in the two encodings, so the importer's UTF-8 decode fails on the 1252 bytes. Converting the file to the importer's expected encoding resolves the mismatch at the source.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LiFaM9xboiWzI_LJUxzfIQ