Architecture
Column Mapping vs LLM Extraction for Vendor Price Sheets
By Vivek Jalondhara · 4 min read
Published
Choose configured mapping, LLM interpretation, or a combined route by examining the actual uncertainty in each vendor file.
A stable CSV with known headers and a spreadsheet with merged headings present different problems. Sending both through the same model prompt can hide a simple mapping task inside a less predictable interpretation workflow.
This educational comparison proposes two ingestion routes for the Sheet Parser domain. It evaluates their responsibilities using fictional vendor formats and a shared draft contract, rather than claiming one approach is universally faster or more accurate.
Identify the uncertainty before choosing a parser
Start by examining the file contract. Are the column names and order controlled? Is the currency supplied explicitly? Does each row contain one product, or can headings and footnotes change the meaning of later rows? These questions distinguish reading a known structure from interpreting an unfamiliar layout.
File parsing itself still needs a correct implementation. CSV can contain quoted fields, delimiters inside values, and embedded line breaks; splitting a line on commas is not a general CSV parser. Establish what formats the application accepts before comparing the later mapping and interpretation stages.
Use mapping for a documented layout
A configured mapping says exactly which source field supplies each draft field. For a known vendor export, SKU may map to productCode and NetPrice to amount. Store the mapping's version and the expected source contract so a changed export can be detected and reviewed.
The helper below checks an already parsed header against one expected ordered header. It is deliberately strict. A match can select a mapping candidate, but it does not prove that the rows still follow the documented currency, unit, or decimal conventions. Validate those properties after mapping.
Use model interpretation for bounded ambiguity
An LLM route can propose which heading represents the price or how a description expresses a selling unit. Give it the relevant source context and a limited output shape. Retain unresolved values instead of allowing the prompt to invent required information to satisfy the schema.
Both routes must produce the same validated draft contract and retain source locations. Otherwise the review interface needs to understand which extraction engine produced each row, and acceptance rules can drift between routes. The model proposes an interpretation; the application owns routing, permissions, and the accepted record.
Make fallback a visible transition
Suppose a known header changes from NetPrice to ListPrice. Silently treating the new label as equivalent could change the meaning of every amount. Route that file to layout review or an explicitly configured interpretation workflow and record why the known mapping no longer applied.
A combined system can let a reviewer confirm a new mapping after inspecting representative rows and source notes. Keep that decision separate from accepting a single extraction result. A one-off successful interpretation is not enough evidence that a permanent mapping will remain valid for future exports.
Compare results on the same documents
Use a small set of synthetic documents with known expected fields. Run the mapping and interpretation routes where each is applicable, then inspect row identity, missing values, unit preservation, and the source evidence available to the reviewer. Measure operational cost and elapsed time separately from correctness.
Include unsupported layouts and malformed files in the comparison. A route that returns an explicit unsupported outcome can be more useful than one that produces plausible incorrect rows. Record the scope of each conclusion so a result for one vendor format does not become a promise about every spreadsheet.
Keep the routing decision easy to explain
An operator should be able to answer which route handled a file, which version of its configuration was used, and why a row needs review. Record those details as application metadata. Avoid asking the model to choose its own permissions or quietly upgrade its output to accepted catalogue data.
The practical choice is often a small set of supported paths with a clear exception route. Begin with the format uncertainty that actually exists, keep the downstream contract stable, and add another extraction mechanism when it solves an identified case that the current paths cannot handle reliably.
Recognise one explicit header contract
This TypeScript helper receives parsed header cells, not raw CSV. It selects only a candidate mapping. The authorised vendor profile, row values, file limits, and source semantics need their own checks.
Illustrative example · TypeScript · Simplified for explanation
function matchesHeader(
actual: readonly string[],
expected: readonly string[]
): boolean {
return expected.length > 0 &&
actual.length === expected.length &&
expected.every((field, index) => actual[index] === field);
}
const expected = ["SKU", "NetPrice", "Currency", "SellingUnit"];
const actual = ["SKU", "ListPrice", "Currency", "SellingUnit"];
const route = matchesHeader(actual, expected)
? "mapping-candidate"
: "layout-review";- Inspect the supported file contract
- Choose mapping or interpretation
- Produce the shared draft shape
- Validate and review the result
Conceptual flow for the example above.
Tradeoff to keep in mind
Strict matching rejects harmless layout changes as well as meaningful ones. Explicit versioned mappings improve repeatability, while an interpretation route adds review and provider considerations.