An invoice CSV breaks when descriptions contain commas or new lines

A description containing a comma or a line break can expose an incorrect CSV import method. If the tool splits every comma into a new column or every physical line into a new record, part of a description can be mistaken for an amount, invoice number or customer. Stop the import and preserve the original file. Deleting punctuation from the descriptions may hide the immediate error while damaging legitimate invoice information.

RFC 4180 documents a common CSV convention in which fields containing commas, quotation marks or line breaks are quoted, and quotation marks inside a quoted field are escaped. It is an informational description of common practice, not a promise that every exporter uses the same dialect. Confirm the exporter and importer's delimiter, quoting and encoding rules. Use a parser that understands the agreed format rather than a simple text split.

Compare a failed record with the original invoice. Note the expected columns and locate the first point where the imported values no longer match them. A comma inside a supplier's description may shift the quantity into the price column. An embedded newline can create what appears to be a second transaction with no invoice number. An unmatched quotation mark can cause several later lines to be interpreted as one field. Each pattern needs a format-level diagnosis.

Check the header and the intended number of fields per record. If the file uses a semicolon as its delimiter, an import set to commas can produce a different failure. Do not assume that the delimiter shown in one sample applies to every file from a different country or software version. Keep the original field values unchanged while testing parser settings. Only convert the file after the source format is understood and the target format is documented.

The row number displayed by an editor may not equal the invoice-record number. A correctly quoted multiline description occupies several physical lines but remains one record. When reporting an error to the exporter, provide a safe, minimal example and the relevant record identifier instead of relying only on the visual line number. Remove sensitive customer information from support examples while preserving the punctuation that triggers the problem.

Prepare a synthetic file with the real column structure and a few deliberate description cases: a comma, a quotation mark, a newline, an empty description and a non-ASCII character where supported. Give each case a distinct invoice identifier and a known amount. Import it into a safe test area and check the resulting field values. These examples are format tests, so they should not create production invoices or send messages to customers.

An illustrative test has four invoice lines with amounts of $100, $200, $300 and $400. The expected total is $1,000 and the expected record count is four, even if one description spans two lines. A parser that reports five rows has not necessarily found an extra invoice. Compare the stable line identifiers and field assignments. A matching $1,000 total alone cannot prove that descriptions and customer references stayed attached to the intended amounts.

Include a round-trip test when staff will edit and re-export the file. A file may import correctly but be saved with a different delimiter, quoting convention or encoding. Re-read that saved copy using the intended downstream parser and compare the records with the test source. Keep the passing test file and expected results with the import instructions. This gives future operators a quick way to check a changed spreadsheet or export setting.

If the source file violates its own declared format, request a corrected export or use a documented repair that can be traced to the source records. Do not silently skip malformed rows and call the remaining import complete. Produce an exception file with record identifiers and reasons. Separate failures caused by file syntax from valid records rejected by business rules, such as an unknown customer or closed accounting period. The people who resolve those exceptions may be different.

Avoid replacing every newline or quotation mark throughout the raw file. That can change genuine descriptions and still leave ambiguity about where a broken record ends. If a limited repair is necessary, apply it to a verified population with an audit of the exact transformations. Compare the repaired invoice information with the underlying documents. Keep the malformed original, the repair procedure and the accepted output so another reviewer can reproduce the result.

Remember that correct CSV quoting does not by itself address spreadsheet formula injection. Text supplied by customers or vendors can have separate security implications when a spreadsheet interprets it. Use an approved export method appropriate for the recipient's application. Do not turn an accounting import repair into an improvised universal sanitization rule; preserve the source values in the authoritative record and test the intended display or import path.

If the broken file already created invoices or entries, identify that import's exact population and current status. Determine whether any records were sent, paid, matched or included in a closed period. Use the application's supported correction process with the accounting owner. Reimporting the full corrected file over the existing records can duplicate legitimate transactions. A targeted retry should contain only verified failures or follow a documented replacement procedure.

After repair, compare invoice counts, line counts and amounts by customer and currency. Inspect descriptions containing the original problem characters and verify their attached documents. Confirm that no fragment became an unintended invoice or shifted an amount onto a different customer. Record the accepted and rejected populations with the import identifier. The release condition is a correctly parsed, correctly associated set of records, with every remaining exception explained.