Treat CSV import as a second data pipeline

A browser job can collect the right records and still hand over a misleading spreadsheet. The CSV may contain an identifier such as 00127, while the workbook shows 127. A price may arrive as source text, then become a number under a different locale. The file opened successfully; the handoff changed its meaning.

That makes spreadsheet import a useful second acceptance boundary. Check the downloaded records first, then check what the receiving workbook preserves. This guide describes a proposed handoff procedure, with fictional examples. It does not report a new browser or Excel test.

Keep the downloaded artifact

Start with a copy of the original CSV. Give the working workbook a different filename, and record which download it came from. If someone later questions an identifier or a missing value, you need evidence from before spreadsheet interpretation.

Keep the collection scope alongside it. “One supplied listing page” is a scope; “the whole catalog” requires separate coverage evidence. A matching row count cannot establish that pagination or every category was collected.

For a small job, a plain handoff note is enough:

{ "artifact": "listing-page.csv", "scope": "one supplied listing page", "record_unit": "one product", "identifier_columns": ["product_id", "product_url"], "raw_columns": ["price_raw", "availability_raw"], "expected_records": 12 } 

These names and the count are illustrative. Derive the real count from parsed CSV records, excluding the header. Counting physical lines is unreliable when a quoted field contains a newline.

Define types by meaning

Decide which columns represent quantities and which represent labels before importing. A product identifier remains a label even if every character is a digit. URLs, postal codes and external reference numbers often belong in text columns too.

A price needs a more explicit contract. Keep price_raw as collected text. If the pipeline also supplies price_amount and currency, document the parsing rules and check them separately. Do not silently turn an unavailable price into zero; zero is a valid quantity with a different meaning.

A compact review table makes those decisions visible:

The goal is not to force every column into one type. It is to stop automatic guesses from becoming undocumented transformations.

Inspect the import preview

Use an import route that exposes encoding, delimiter and column types. In Excel versions that provide it, Data → From Text/CSV is a starting point; the available controls vary by version and platform.

Microsoft documents both CSV import behavior and preserving leading zeros through text column types. Check the instructions for the receiving environment rather than assuming a double-click uses your intended types.

In the preview, look for a single column containing the entire row, split fields caused by the wrong separator, and damaged characters. Then inspect type conversion steps. Changing a column to text after a destructive conversion may not recover its original value; return to the preserved artifact and correct the import.

Check values, then save the workbook

Choose a few deliberate samples rather than only the first row: an identifier with a leading zero, text with punctuation, an empty optional field, and a price whose interpretation could depend on locale. Compare their workbook values with the parsed source records.

Reconcile the full record count as well. If one product occupies several rows after import, check parsing and the chosen record unit before deleting duplicates. Multiple observations of the same product may be legitimate; use the collection contract to decide.

When the deliverable needs formulas, formatting or multiple sheets, save a separate XLSX workbook. Renaming a CSV extension does not create those workbook structures. Reopen the saved workbook and repeat the sensitive-value checks, especially if a different person will receive it.

Make the handoff reproducible

Deliver the original CSV, the working workbook and the short import note together. Record any intentional transformations, the check date and who performed the review. Keep calculated columns distinguishable from collected fields so a future refresh does not overwrite evidence or mix old formulas with new records.

BrowserAct's website-to-Excel walkthrough supplies the collection-side context: one record per row, native CSV output, then spreadsheet import. The extra acceptance boundary here is the receiving workbook. A useful delivery proves that the intended records survived both stages.