A company-store export should have a declared destination: a person reviewing orders or a system importing them. Do not treat one CSV as both a convenient spreadsheet and a production-ready instruction file. Preserve identifiers as text, define the row structure, keep recipient-entered content from becoming spreadsheet formulas, and verify any edited file before it can trigger fulfillment.
The practical decision is not “CSV or Excel?” It is whether the handoff preserves the meaning of an order. A file that opens successfully can still change a postal code, split a personalization message across rows, or repeat an order-level charge on every line. Those are different failures, and each needs a different check.
Publisher perspective: Brand Sauce publishes this operating guide for company-store buyers and administrators. The controls below are recommended acceptance criteria, not claims that every store platform or Brand Sauce configuration already provides them. Confirm the actual export and import behavior with the provider.
Separate the review copy from the import file
A finance reviewer wants sortable rows, recognizable column names and useful totals. A fulfillment integration needs stable field names, exact identifiers and a documented schema. Combining those needs in an informal “master spreadsheet” makes it difficult to know which version is authoritative.
| Output | Purpose | Required boundary |
|---|---|---|
| Human review workbook | Find exceptions, reconcile costs, assign follow-up | Recipient text remains text; edits do not automatically update orders |
| Machine import file | Send approved records to a named receiving system | Exact schema, validated values and explicit release approval |
| Restricted source snapshot | Resolve a discrepancy against the original export | Unedited, access-controlled and retained only under the program’s retention policy |
These can originate from the same transaction data without being interchangeable. Give each a distinct filename and purpose label. For example, a review workbook might carry an “analysis only” note, while the production file has a batch identifier, schema version and named receiving system. Do not place the review copy in a folder that an automated importer watches.
If the team only needs to count orders by department, request that report without home addresses or gift messages. Decide which fields are necessary before the download, as described in our employee gifting data handoff guide.
Write the row contract before checking totals
Ask what one row represents: an order, an order line, a shipment, a recipient or an individual unit. An export with one row per shipment is not a safe substitute for an order-line export when a single line can ship in parts.
Use an order identifier plus a line identifier when the task is line-level work. Product names are not reliable record keys: a name can change, two variants can share it, and a recipient can order the same product twice. Include the store or account scope if order identifiers are only unique within that scope.
Illustrative example: one order has two lines: two shirts and one bottle. A line-level export should contain two rows and a total quantity of three. If the order’s delivery charge is $8, seeing $8 in both rows does not mean shipping cost $16. The schema must say whether that field is repeated order information, allocated line cost or something else. These are invented figures to demonstrate reconciliation, not a supplier quote.
Record the export’s filters and snapshot time, including time zone. “All orders” is incomplete if the interface quietly excludes canceled orders or only includes shipments created this week. Comparing a morning export with an afternoon dashboard may reveal timing differences rather than missing transactions.
For ongoing reconciliation, retain separate counts for distinct orders, distinct lines and total units. Add shipment count only when it answers a shipment question. Our company-store invoice reconciliation guide explains the broader financial handoff; the export contract makes that handoff interpretable.
Protect text fields before the spreadsheet interprets them
Identifiers are labels, even when they contain only digits. Treat order IDs, employee reference IDs, postal codes, phone numbers and product codes as text unless the receiving specification explicitly says otherwise. Treat quantities and monetary amounts as numbers only under their documented rules; include currency separately where needed.
Microsoft’s Power Query Text/CSV documentation provides controls for delimiter and data-type detection, including disabling automatic detection so columns default to text. It also warns that inference can be incorrect. Use a deliberate import step and inspect the types before loading, rather than relying on a double-click opening workflow.
For a review process, our recommended sequence is to load the source into a staging table as text, check identifiers against the source, then deliberately convert only the columns needed for calculation. Review any automatically inserted conversion step. A later “format as text” operation is not a substitute for preventing an earlier interpretation.
| Field | Review rule | Acceptance example |
|---|---|---|
| Postal code | Text, not a quantity | An illustrative code of 02108 keeps its initial zero |
| Order reference | Exact source string | Leading zeros and long identifiers survive unchanged |
| Quantity | Validated number in the stated order unit | Two packs cannot silently become two individual items |
| Timestamp | Declared format and time zone | The reviewer can identify the same instant in the source |
| Gift message | Literal text in one field | Commas, quotes and line breaks do not create extra records |
For names and messages containing accents or non-Latin characters, verify encoding as a separate issue. Microsoft’s UTF-8 CSV guidance explains its normal-opening behavior with a byte order mark and offers import routes otherwise. Include representative synthetic characters in the test file; do not “fix” a damaged name by guessing its intended spelling.
Treat recipient-entered text as data, not formulas
Company-store records may contain names, personalization requests, addresses and gift messages entered by recipients. Their presence in an export generated by your own store does not make those values trusted spreadsheet instructions.
OWASP’s CSV Injection guidance describes how spreadsheet software can interpret untrusted exported cells as formulas. It identifies formula-initiating characters, separator-related issues and important differences between spreadsheet applications. It also warns that saving and reopening a CSV can undermine some escaping approaches, and that there is no universal sanitization strategy for all spreadsheet and downstream consumers.
That is why “we put quotes around every field” is not an adequate acceptance answer. Ask the provider how exported free text is serialized, how spreadsheet interpretation is handled, and which applications and save/reopen workflows have been tested. A human-viewing transformation can alter underlying data, so it should not silently become the machine-import representation.
Where a provider supplies a workbook instead, ask whether untrusted fields are written as literal string cells rather than formulas. The file extension alone is not evidence. Your technical owner should approve the implementation and test the actual receiving tools; administrators should not improvise a universal character-stripping rule that changes legitimate names or messages.
Use harmless synthetic input for the review. A literal message containing =1+1 should stay the literal text, not display the calculated answer. Do not use external-link formulas, commands or real employee data for this check. Security warnings are a stop-and-investigate signal, not a routine instruction to enable content.
Test the whole handoff, including save and reopen
A useful acceptance exercise follows the route people will actually take. Testing only the initial export misses the reviewer who saves a new CSV and forwards it to another team. Run the exercise outside production fulfillment, using a synthetic dataset and a receiving-system preview where available.
- Define the expected result. Specify row grain, keys, column names, encoding, delimiter, types, currency and allowed status values. Name the applications and versions in scope.
- Build a small fixture. Include a multi-line order, a leading-zero identifier, a long identifier, a name with an accent, a quoted message containing a comma, a line break, a blank optional field and the harmless literal-formula example.
- Open through the approved path. Check the displayed values and the underlying cell types. Verify that no message becomes a calculation and no quoted field creates a new row.
- Perform the real review operations. Sort, filter and add review notes in the working copy. Confirm that sorting preserves entire records and that helper columns cannot leak into the production schema.
- Save, close and reopen. Repeat the checks in every supported downstream application. Record the file format used at each step, not just the application name.
- Preview the machine import. Compare exact keys, line count and quantities against the approved source. Require a separate release action before any stock allocation, printing or shipping.
A failed check should identify the affected field and transition: source to CSV, CSV to workbook, workbook to saved file, or file to receiver. That is much more actionable than “Excel broke it.” These are proposed acceptance checks, not tests we claim to have performed on a particular vendor’s export.
Keep spreadsheet corrections from becoming duplicate orders
An export is usually a snapshot, not a live editing interface. If a reviewer changes a shipping address in a local workbook, the original order may still contain the old address. If they upload the entire workbook to “apply the fix,” the receiving process might instead create new orders.
Route corrections back through the authoritative order workflow. Record the order and line keys, field to change, approved new value, requester and disposition. Re-export after the approved change when practical. Avoid circulating complete recipient lists just to resolve one exception.
Before allowing updates through an import, establish whether the receiver creates, updates or upserts records, what key it matches, and how it handles repeated batches. Confirm that a rejected row is reported without pretending the whole file succeeded. Our bulk imports versus employee checkout guide covers when that ordering model is appropriate.
The same controls matter with on-demand, bulk and hybrid programs. On-demand can reduce finished-stock commitments but cannot rescue a misinterpreted address or repeated production instruction. Bulk can suit a known event quantity, while a hybrid program may combine stocked items and individual production. In each case, the export must distinguish order units and fulfillment routes before release.
A copyable export acceptance card
- Business purpose and recipient: who needs this file, and what decision or transaction does it support?
- Snapshot: store, filters, timestamp and time zone.
- Structure: one row per ___; unique key ___; schema version ___.
- Field rules: text identifiers, numerical units, currency, encoding and delimiter.
- Spreadsheet controls: literal-text treatment, approved applications and tested save/reopen path.
- Control totals: distinct orders, lines and units; financial totals with repetition rules stated.
- Correction and release: authoritative update route, duplicate-batch handling and release owner.
- Access and retention: permitted readers, storage location and deletion or retention trigger.
Keep this card beside the provider’s sample export. A clean-looking demonstration without a defined row contract or round-trip result is not yet an accepted handoff.
Frequently asked questions
Is CSV inherently unsuitable for company-store orders?
No. A documented CSV can be an effective machine exchange format. The problem is assuming that every spreadsheet will interpret it identically, or that a human-edited review file remains suitable for production import.
Should every field be text?
Text-first staging is useful for preserving the source during review. Calculations still need intentionally typed numeric columns, and machine imports must follow their agreed schema. Do not change a receiver’s field types without coordinating the change.
Can we use a spreadsheet just to approve an order?
Yes, if approval is linked to stable order identifiers and routed back through a controlled release process. A colored row or a forwarded attachment should not be the only evidence that the production system accepted the approval.
What is the first thing to ask an export provider?
Ask for a synthetic sample, its field dictionary and a demonstration of the intended opening and re-import workflow. Then ask what one row means. That answer determines almost every reconciliation check that follows.
