Before importing a wholesale catalog, check at minimum the product identifier, the variant identifier, the label, the brand, the price and its tax nature, the currency, the stock, the sales unit, the minimum order quantity, the image, and the timestamp. A column being present is not enough: you also need to know its definition, its format, and its level of precision. A stock field containing "yes" does not prove a quantity, and a price field without a currency or an indication of tax-excl./tax-incl. does not allow a reliable profitability calculation. The right approach is therefore to build a column dictionary, test a few rows, and block the import as soon as an ambiguity affects identity, price, or orderable quantity.
Start with meaning, not the column name
Two suppliers can call EAN different kinds of data. For one, the value designates the variant sold; for another, it may be empty, truncated by a spreadsheet, or duplicated across every color. Conversely, article_code, reference, or barcode may contain the actually useful identifier. The header name is therefore never proof.
Request the feed documentation and map each column to four pieces of information: business definition, data type, unit, and update rule. For a price, note for example whether it is a retail or negotiated price, tax-excl. or tax-incl., per unit or per carton. For a stock field, distinguish numeric quantity, simple availability, and free text. For an identifier, keep the value as a string so you don't lose leading zeros.
GS1 states that the GTIN identifies a trade item and that its representation can vary depending on the exchange standard. In GS1 XML, it is notably represented on fourteen digits with left-padding, while other formats accept a variable length. This justifies controlled normalization, but not inventing a missing code. GTIN check-digit validation must happen before any deduplication.
The priority control grid
| Family | Columns to look for | Validation question | Decision if proof is missing |
|---|---|---|---|
| Identity | GTIN/EAN/UPC, SKU, MPN | Does the code belong to the variant being sold? | Put the row in review |
| Description | name, brand, variant | Are size, color, or quantity explicit? | Do not auto-merge |
| Price | price, currency, tax-excl./incl. | Does the amount apply to the orderable unit? | Block the margin calculation |
| Stock | quantity, availability | Is it a number, a boolean, or a lead time? | Keep the exact level of proof |
| Order | MOQ, increment, carton | How many units do you actually need to buy? | Do not infer from the title |
| Media | main image | Does the image match the right variant? | Exclude from visual matching |
| Time | update date | When were price and stock observed? | Flag the data as undated |

This table should be filled in with real examples from the file. Empty cells, 0, N/A, and null do not necessarily mean the same thing. A quantity equal to zero may signal an out-of-stock item; an empty cell may signal "unknown," "not applicable," or simply an export error. Only the supplier's documentation can settle the question.
A reproducible procedure before import
1. Keep the raw file, its receipt date, and a control checksum. Never correct the original. 2. Read the encoding, the separator, and the headers without first opening the file in a spreadsheet tool that might reformat the identifiers. 3. Pull a small, diverse sample: a simple product, a variant, an out-of-stock item, a possible discount, and a row with empty fields. 4. Build the column dictionary using the supplier's official documentation and flag every unconfirmed interpretation. 5. Check GTINs as strings, then validate their allowed length and check digit. A mathematically valid result, however, proves neither attribution nor a match to the product. 6. Recalculate the unit price from the sales unit, the explicit packaging, and the minimum order quantity. Do not infer a pack from a photo. 7. Compare at least two rows of each business case against the official listing or the supplier portal. 8. Import a canary batch, watch for rejections, and only scale up if the rules stay stable.
The goal is not zero empty cells. It is to never turn an absence of proof into a certainty. A partial but correctly typed catalog is more usable than a seemingly complete file whose units are ambiguous.
The mistakes that silently distort an analysis
The first mistake is automatically converting GTINs into numbers. Scientific notation, the loss of a leading zero, or an added decimal renders the value unusable. The second is taking the most visible price as a purchase cost: it could be a recommended retail price, a promotional rate, or a per-lot amount. The third is translating InStock into an arbitrary quantity. Schema.org defines InStock as an indication of availability; on its own it does not provide the number of units.
Also check for duplicates. The same GTIN repeated across several rows is not automatically an anomaly if those rows represent distinct warehouses or offers. It becomes dangerous when it is attributed to genuinely different variants. The detailed diagnosis is covered in the method for detecting variant duplicates.
Finally, separate received fields from calculated fields. prix_source, devise_source, and stock_source (source price, source currency, source stock) must remain traceable. Conversions, scores, and assumptions belong in distinct columns with a date and an explicit rule. Without this separation, a later correction becomes impossible to audit.
Decision checklist
- The raw file and its timestamp are kept.
- Every identifier stays a text string.
- The GTIN matches the variant and passes its check digit.
- The price is linked to a documented currency, unit, and tax-excl./incl. nature.
- Numeric stock is not confused with boolean availability.
- MOQ, order increment, and carton contents are kept separate.
- The main image is an official URL linked to the right variant.
- Empty and null values have a documented interpretation.
- Transformations are distinct from source data.
- A canary batch has been checked before any significant volume.
What ArbitragePro+ can automate / what the seller must verify
The proposed controle-colonnes-catalogue specification could detect headers, type the values, flag invalid GTINs, surface missing currencies, and classify stock by its level of precision. It would produce a report of evidence and ambiguities, without deciding on the supplier's behalf.
The seller must contractually confirm the meaning of the fields, the tax nature of prices, the orderable units, the usage rights of the feed, and the consistency of variants. They also remain responsible for verifying that the transformations reflect their own commercial terms.
Moving from diagnosis to a tracked catalog
View the ArbitragePro+ Sources page to review the available connectors and provenance information.
Official sources
- GS1, «Global Trade Item Number (GTIN)», https://www.gs1.org/standards/id-keys/gtin — accessed 2026-08-17.
- GS1 Support, «Required format of GTIN in GS1 EDI standards», https://support.gs1.org/support/solutions/articles/43000734355-what-is-the-required-format-of-gtin-in-gs1-edi-standards- — accessed 2026-08-17.
- Schema.org, «ItemAvailability», https://schema.org/ItemAvailability — accessed 2026-08-17.
