Supplier Data Is an API Even When It Arrives as Excel

A supplier workbook arrives by email instead of through an HTTP endpoint. That changes the transport, not the fact that another organization controls the input. The workbook can change its columns, omit records, reinterpret a code or arrive later than expected. Every downstream automation depends on how those changes are handled.

Working with catalogue data makes this boundary difficult to ignore. A spreadsheet often looks informal because a person can open it and inspect the cells. Once software consumes it repeatedly, it becomes an external interface with a contract, failure modes and an operating history.

A spreadsheet from another company is still an external dependency.

Start with what the file promises

The contract should describe the dataset, not merely the format. Does the file contain a complete catalogue or only changed products? Does an absent row mean deletion, temporary unavailability or nothing at all? Are prices current immediately or effective on a future date?

These distinctions determine safe behavior. Treating a partial update as a complete snapshot can remove valid products. Treating a complete snapshot as a partial update can leave obsolete records active. Neither error requires malformed data; the file can be perfectly readable.

Ask which fields are required and what an empty value means for each. A blank description might mean “no description supplied,” while a blank stock value might mean “unknown.” Converting both to an empty string or zero can erase a distinction the business needs.

The W3C tabular data model provides a formal way to describe tables and associated metadata, including columns and relationships. A supplier integration need not implement the whole specification to benefit from the underlying discipline: meaning must be represented alongside cell values.

Preserve the received artifact

Keep an immutable copy of the file as received, with a receipt timestamp and a content hash where useful. The original artifact helps answer whether a strange value came from the supplier, a parser, a mapping rule or a later manual correction.

Do not use a filename alone as identity. Suppliers may repeatedly send catalogue.xlsx, and an operator may rename a file before processing it. A recorded hash identifies the actual bytes more reliably than a human-readable label, while the label remains useful context.

Provenance should continue through transformation. A rejected row should point back to its source file and location. A published record should retain enough mapping information to explain which supplier reference produced it, without exposing unnecessary internal details to customers.

This is particularly useful when the same product appears in several feeds. The internal catalogue needs to distinguish product identity from the provenance of each supplied fact. Otherwise the latest import can silently become authoritative merely because it ran last.

Normalize deliberately

Normalization can make inconsistent input easier to process, but every normalization rule makes a judgment. Trimming surrounding whitespace is often reasonable. Removing punctuation from an identifier may merge values that the supplier considers distinct. Converting a blank numeric cell to zero can create a false statement.

Define rules per field. Product references should usually remain strings. Numeric fields need explicit units and decimal conventions. Dates need a known interpretation, particularly when a value represents an effective local business date rather than an instant.

Spreadsheet software can also affect representation before the integration sees the file. Leading zeros, scientific notation and displayed formatting may differ from the underlying value. Inspect the actual data contract and parser behavior instead of assuming the visible cell is the complete meaning.

Keep normalization separate from validation. A normalized value can still be invalid. Record important transformations so an operator can explain why the published representation differs from the source, especially when the difference could affect matching or price interpretation.

Treat schema drift as a visible event

A new column may be harmless. A renamed required column may be breaking. A column with the same name but a new unit can be more dangerous than either because the parser continues to succeed.

Compare the received schema with the expected contract. Report missing required fields, unexpected duplicates and changes in recognized columns. Decide explicitly whether unknown columns are ignored, retained for inspection or treated as a reason to pause the import.

A successful parse should not conceal a changed agreement.

For high-consequence fields, validate meaning as well as presence. If a quantity previously represented units and now represents cases, a header check alone will not protect the workflow. Packaging context and business review may be necessary to detect the change.

A small versioned mapping file can make these rules inspectable. It should identify which supplier format it expects and how each field maps into the internal model. Avoid a collection of undocumented special cases scattered through transformation code.

Make acceptance a separate stage

Receiving a file should not immediately make its contents authoritative. A useful pipeline distinguishes receipt, parsing, validation, review where needed and publication. Each stage produces evidence that the next stage can inspect.

A batch summary might include the source identity, recognized schema, accepted and rejected counts, new products, changed values and proposed removals. The important differences deserve more attention than the raw number of processed rows.

For example, a file that proposes removing most of a catalogue may indicate a partial export or a changed supplier scope. The appropriate response is to pause and investigate according to a documented rule. It should not depend on an operator happening to notice a small warning in a long log.

The catalogue automation guide develops this distinction between syntactic success and meaningful correctness. A receipt can be technically valid while requiring a human decision before its consequences become public.

Plan for late and repeated files

External files do not always arrive once and in order. A supplier may resend a corrected workbook with the same name or deliver an older revision after a newer one. The import needs a policy for duplicates and superseded data.

Receipt time and effective time are different facts. A late file may contain valid historical information that should not replace current values. Where the supplier supplies a revision or effective date, preserve it and define how ordering works. Where that information is missing, do not invent certainty from the email timestamp.

A repeated artifact can often be recognized by its hash, but identical bytes do not settle every business question. The same snapshot may be intentionally resent as confirmation. Keep the distinction between “already processed” and “invalid” clear in the operational report.

Recovery should also be explicit. If publication fails after validation, the system should be able to resume from the accepted artifact without asking someone to reconstruct the original spreadsheet manually.

Transport security and access control still matter for file-based exchange. Store received artifacts where only the relevant operators and jobs can read them, and avoid using a public web directory as a convenient inbox. The fact that a file arrived through email does not establish that every recipient should retain or redistribute it. Define the authorized intake path and the retention policy alongside the parsing contract.

Give exceptions an owner

Some failures are technical; others require domain judgment. An unreadable workbook can be reported as a parsing problem. A supplier reference that could match two internal products needs a mapping decision. A surprising price change may require commercial confirmation.

Route these cases to the right owner with enough evidence to act. A generic “import failed” message sends every problem back to the person who wrote the script, even when the answer belongs to purchasing or catalogue operations.

Keep private supplier details out of broad logs and public documentation. The exception report should contain the information needed for authorized review, while general monitoring can record categories and counts. Operational visibility does not require copying the entire source dataset everywhere.

The interface becomes dependable when a received file has a known meaning, changes are visible and exceptions have a clear path to resolution. At that point the spreadsheet’s informal appearance stops dictating the reliability of the integration. It is treated with the same care as any other external contract.

Sources

1. W3C tabular data model — checked 2026-10-14