Count CSV records correctly when cells contain line breaks

Investigate the count before deleting a line

A support ticket says an export has four lines but only two orders. Both observations can be correct. The header occupies one physical line, the first order has a note spanning two physical lines, and the second order occupies one. Removing the apparent extra line would damage the note.

Use a copy of the following synthetic sample. The expected result is two data records, two columns per record and an embedded newline in the first note. There is no requirement that a record occupy a single display line in a text editor.

order_id,note
A-17,"Leave at reception
Call on arrival"
A-18,"Hand to recipient"

RFC 4180: quoted CSV fields and record structure ↗

Use quoting rules to find the record boundary

In the common comma-separated format, a quoted cell can contain commas, double quotes and line breaks. A literal double quote inside the cell is written twice. The closing quote matters: counting commas or splitting the file at every newline is not a CSV parser.

Choose comma as the delimiter for this fixture in KitForma CSV to JSON. Its output should contain two objects with the exact order_id values A-17 and A-18. The first note should contain a newline between reception and Call. The tool keeps cell values as strings, so this inspection does not decide business data types.

Expected first note as JSON text:
"Leave at reception\nCall on arrival"

Expected IDs in order: A-17, A-18
Expected objects: 2

Split complete records, then write new CSV files

If a receiving system accepts one order per file, make two parsed record groups and write a header into each output. The first output still has an embedded newline in its note. Do not cut the raw source after its second physical line, because that would leave an unclosed quoted field.

For a real batch, make a manifest of expected IDs per part and compare the combined output IDs with the original list. Check for missing and repeated IDs, total record count, header order and a sample multiline value. Retain stable identifiers even if a spreadsheet hides the detail column during review.

1. Preserve the source and identify encoding, delimiter and header policy.
2. Parse complete records using a CSV-aware tool or library.
3. Group parsed records within the receiver’s limit.
4. Write each group with the intended header and quoting.
5. Reopen each output and compare counts, IDs and note values.

Classify failures instead of trimming data

An unmatched quote can cause several lines to appear as one unfinished record. A wrong delimiter can make an entire line appear as one column. Compare the earliest reported failure with the source export. Do not remove quotes merely because the file then opens; that can move note text into another column.

Line Counter remains useful for investigating physical layout, but its answer is not an order total. KitForma’s text converters have bounded inputs; for a large export, obtain a smaller complete-record sample from the producer rather than truncating the raw file at an arbitrary byte or line.

Q: Should the header count as an order?

No for this fixture: the header defines two column names and the two following parsed records are orders. Some files have no header, so document that choice before importing. Treat an accidentally repeated header in the middle as a separate data quality issue.

Q: Does a final newline create another order?

A normal final record separator does not add an order in KitForma CSV to JSON. An additional empty record inside a file may have different handling or fail column checks. Verify the parser’s actual behavior instead of compensating by subtracting one from every line count.