Buy sheet automation
Turn a vendor catalog into a finished buy sheet.
Drop the season's catalog, line sheet, or order form in. Get back a complete buy sheet — one row per SKU, with photo, style number, category, color, delivery window, and wholesale and retail pricing in every currency you buy in. Minutes, not the week your team currently spends re-keying it.
[01]The walkthrough
One catalog in. One finished sheet out.
No template to prepare, no field mapping to configure at run time, no cleanup pass afterwards. The buyer submits the season's files and reviews what comes back.
[02]The current process
The buy sheet is rebuilt by hand every season, for every brand.
The catalog arrives as a PDF. The order form arrives as a spreadsheet with a different header row. The pricing arrives in a third file, in three currencies. Someone opens all of them side by side and types.
[01]
It is re-keyed, not imported
Style numbers, product names, colors, size runs and delivery windows are read off a page and typed into a template. Nothing about the source file is machine-readable in the shape the buy sheet needs.
[02]
It repeats per brand, per season
Every vendor formats its catalog differently, and reformats it between seasons. The work does not get faster the second time, because the layout changed.
[03]
The errors are found downstream
A transposed style number or a wholesale price in the wrong currency column surfaces at order entry, at the invoice, or at receiving — after it has cost something to be wrong.
[04]
It blocks the actual decision
Buying is the judgment call about what to take and in what depth. The days before it are data entry standing between the buyer and the decision.
[03]How it works
Five steps, and only one of them is yours.
[01]
Drop the files where you already work
Catalog PDFs, line sheets, order forms, price files — several at once, in whatever formats the vendor sent. No template to fill in first, no portal to log into, no file naming convention to learn.
[02]
Every page is read, not parsed
A vision model reads each page the way a person does: it finds the product cards on the page, then reads the fields out of each one. That is what makes it survive a catalog laid out as a lookbook, where there is no table to parse.
[03]
Every value is checked against the source
Each extracted value is verified against the document's own text layer before it is written. Values that confirm are written. Values that cannot be confirmed are flagged for review or left blank with a note — never quietly filled in with the model's best guess.
[04]
Sources merge into one sheet
A catalog, an order form and a price file describing the same season are merged on the SKU, with a stated precedence for which source wins on a conflict. Pricing is routed to the right currency column rather than pasted into the first one.
[05]
The sheet comes back finished
An Excel workbook and a live spreadsheet, in your template, with totals and margin. Rows that need a human look are colored and listed, so review is a short queue rather than a full re-check.
[04]What comes back
A finished sheet, in your template, not a data dump.
The output is the file your team already works in — the same columns, the same order, the same template. It is not a generic export somebody then has to reshape.
Every row carries
- Product photo
- Style number
- Division
- Category and subcategory
- Product name
- Color
- Size run
- Delivery window
- Wholesale price
- Retail price
- Per-currency pricing
- Margin
One row per SKU
Every product in the catalog, at the level of granularity your buy sheet uses, with the product image embedded in the row rather than referenced by filename.
Every currency you buy in
Wholesale and retail in each currency, routed to the correct column. Where a source states one currency and the master states another, the conflict is surfaced rather than silently resolved.
Review is a short queue
Rows with a value that could not be confirmed are colored and enumerated. A reviewer looks at the exceptions, not at all four hundred rows.
Excel and a live sheet
A workbook for the people who want a file, and a live spreadsheet for the people who want to work in it together. Both are produced from the same run.
[05]Why it does not guess
An extraction agent that invents a price is worse than no agent.
The failure mode that matters is not a missing value — a person can see a blank. It is a confident wrong value, which looks exactly like a right one and gets found at the invoice. The system is built around not producing that.
Verified against the source
A value is written because it was confirmed against the document it came from, not because the model produced it. Unconfirmed values are flagged or left blank with a review note.
Deterministic before reasoning
SKU anchoring, header mapping, currency routing and merge precedence are code, not prompts. The model is reserved for the parts that genuinely need reading and judgment, which is also what keeps the per-run cost low.
Every run is evaluated
Accuracy is measured against hand-verified sheets on every change. A change that regresses the score does not ship. Coverage and per-field accuracy are numbers, not impressions.
Every run is on the record
Each run keeps its input files, its intermediate decisions, its cost and its duration. When a cell is questioned, the answer is a lookup rather than a re-run.
[06]Where a person decides
Agents propose. People approve.
Nothing reaches a system of record without a signature. The agent stages the sheet and waits — the buyer confirms the defaults it detected, reviews the flagged rows, and merges. Until that happens, the agent has produced a draft and nothing else.
- The agent states what it inferred from the files before it runs, and the buyer corrects it.
- Flagged rows are listed by exception, with the reason each one was flagged.
- The merge is an explicit action taken by a person, and it is reversible.
- Pricing sources and their precedence are set by the buyer, not chosen by the model.
[07]Definition
What is a buy sheet?
A buy sheet is the working document a wholesale buyer builds from a vendor's seasonal catalog: one row per SKU, carrying the style number, product name, color, size run, delivery window, and wholesale and retail pricing, in each currency the buyer purchases in. It is the artifact the buying decision is made on and the source the purchase order is written from. Most teams still assemble it by reading a vendor PDF and typing into a spreadsheet template.
[08]Questions
What buying teams ask before the first run.
- What file formats does it accept?
- Vendor catalog PDFs, line sheets, order forms and price files in Excel or CSV, and image-only scans. Several files can be submitted together for the same season and are merged into one sheet.
- What if the catalog is a lookbook with no tables in it?
- That is the normal case. Pages are read visually — product cards are located on the page and their fields are read out of the layout — so a catalog with no extractable table structure is handled the same way as a clean grid. A text layer, where one exists, is used to verify what was read rather than to do the reading.
- How accurate is it?
- Accuracy is measured per field against hand-verified sheets, and the number is reported for your documents during the pilot rather than quoted from someone else's. The design target is that any value the system is not certain of is flagged rather than written, so the number that matters to a buying team — how often a written value is wrong — stays very low even where coverage is imperfect.
- Does it work with our template?
- Yes. The output is written into your buy sheet template, with your columns in your order. Mapping to the template is configured once per team, not per run.
- Where does it run, and who can see our pricing?
- The agent is deployed into your own cloud environment and works on files you already hold. Your documents and your pricing stay inside your deployment. What carries between deployments is engineering knowledge, never your data.
- How long does a season take?
- A single catalog is typically minutes, scaling with page count rather than SKU count. The work that took a week of re-keying becomes a review pass over the flagged rows.
- What happens when a vendor changes its catalog layout next season?
- Nothing on your side. Because pages are read rather than parsed against a fixed layout, a reformatted catalog does not require a new template or a re-integration. The layouts that do defeat it are treated as a fix in the agent, not as a task for your team.
- Can it handle several brands with different formats?
- Yes — that is the usual deployment. Each vendor's format differs, and the per-vendor handling lives in the agent rather than in a spreadsheet macro somebody on the buying team maintains.
[09]Request a demo
Bring one vendor catalog. See the sheet it produces.
The fastest way to judge this is on your own files. Send one catalog and the template you want it written into, and you get back the sheet it produces, including whatever it could not confirm. The conversation after that is with the engineer who would deploy it.
What happens next
- [01]You get a reply from the engineer who would deploy it, not a nurture sequence.
- [02]One call about your catalogs, your template, and the currencies you buy in.
- [03]A run on one of your own catalogs, with everything it could not confirm listed.
Request a demo.
Name, company, and which brands you buy is enough.