Pricor: Local AI Reads Supplier Tables, Precision Engine Calculates Prices

A table sent by a supplier has a price column showing 12.100,00, with the header marked c/IVA (VAT included), another column showing 10+5, and yet another column showing 100. What is the net cost per unit? The answer is 85.50: two layers of cascading discount (not a simple 15% sum), removing VAT, and then splitting a whole box into 100 units. A small shop owner in Argentina has to calculate this by hand every time they receive a supplier quote—each supplier, each format is different, and next week a column may have moved again.

Pricor (price + order) is a local application built to eliminate this repetitive work. It converts Excel or CSV files into consistently structured, importable product records: supplier code, description, net unit cost and currency, while preserving row-level traceability. Its core principle is just one: the model understands, the engine calculates, the user decides.

A scenario repeatedly calculated by hand

The root of the problem isn't the arithmetic itself, but the chaos of table formats. The same VAT-inclusive price may have a dozen different notations; discounts are sometimes written in one cell (10+5), sometimes spread across two columns; packaging specifications and units of measure are mixed together; the VAT rate may be implied in the header text. The human eye can still guess based on experience, but every guess can be wrong, and the cost of an error goes directly into pricing.

Pricor's processing pipeline is deterministic: first, a rule-based analyzer finds the header row, row types, column types and number formats, ensuring that 12.100,00 is not misread as 12.1; then a fine-tuned multilingual model, Laya, assigns each column to a closed set of roles; columns where Laya is uncertain are handed to Gemma 4 E4B running locally via Ollama; and whatever remains uncertain is put to the user to answer.

All questions are deterministically generated from the information missing in the plan: is the price tax-inclusive? Is it per pack or per unit? What currency? Gemma can offer suggestions and display its (uncalibrated) confidence, but it never makes any decision on the user's behalf.

VAT (IVA) and tax-inclusive/tax-exclusive prices

IVA (Impuesto al Valor Agregado) is the value-added tax commonly used in Spanish-speaking countries; Argentina's standard rate is 21%, with some goods subject to differentiated rates such as 10.5% or 27%. Supplier quotes often mark prices as c/IVA (con IVA, tax-inclusive) or s/IVA (sin IVA, tax-exclusive), but abbreviations and notations are not standardized. Converting a tax-inclusive price to net cost requires dividing by (1 + tax rate), not simply subtracting the tax percentage—for example, a price including 21% tax divided by 1.21 gives the pre-tax net amount. When the tax rate is implied in the header text rather than in a separate column, correctly identifying the rate itself constitutes a parsing challenge, which is one reason Pricor needs models to participate in column role determination.

Cascading discount

A cascading discount means multiple discounts applied sequentially to the decreasing amount, rather than adding the percentages together. 10+5 means first a 10% discount, then a 5% discount on the discounted price; the actual discount rate is 1 − 0.90 × 0.95 = 14.5%, lower than the intuitive 15%. The more discount tiers, the greater the deviation from simple addition. Suppliers often use this notation to express tiered concessions, and in tables it is sometimes written in one cell (10+5), sometimes in two separate columns; the parser must distinguish between "cascading" and "parallel" semantics, otherwise it will systematically overestimate costs.

Calculations are not given to the model, but to a precision engine

This is Pricor's most noteworthy design trade-off. The executor only understands a closed set of operations: parsing numbers, applying cascading discounts, removing VAT, splitting packaging, mapping values, normalizing text, and optional currency conversion. It never executes model-generated code, and it never hands the final price to the model for calculation.

The worked example in the original demo fully illustrates this pipeline:

12,100.00   per box, including 21% VAT
 × 0.90 × 0.95   10% and 5% cascading discount
 ÷ 1.21          remove VAT
 ÷ 100          100 units per box
=    85.50 net unit cost

All intermediate steps are displayed as a "receipt", and the user can verify from the original cell all the way to the final cost, approving only after confirmation. Rejected rows are not silently discarded, but kept in a separate exportable report.

Decimal exact arithmetic and floating-point errors

If monetary calculations use IEEE 754 double-precision floating point, binary representation errors such as 0.1 + 0.2 not equaling 0.3 will accumulate over multiple multiplications and divisions, causing cent-level deviations. Pricor's executor uses the Decimal (decimal fixed-point) type to perform parsing, discounting, tax removal and splitting, ensuring results are consistent with manual calculation under decimal rules and reproducible. This is also one of the technical justifications for "not handing the final price to the model": a language model outputs a token sequence, not an auditable numeric type, and cannot guarantee rounding behavior.

Local models are in the import path, not an add-on chat box

Pricor's use of open-source models is quite instructive: Laya and Gemma sit directly on the critical path of data import, and their judgment boundaries determine when the application must ask the user questions. This design brings several practical benefits.

Privacy. A small shop's supplier lists and cost data never leave their own computer for a hosted model provider. Cost. When importing the same supplier each week, reusing a saved plan incurs no per-call fees; electricity, hardware and support are not free, but there is no meter running. Offline. Importing requires no internet connection; only the optional online exchange-rate refresh needs the network, and cached or manually entered rates work equally well. Licensing. Gemma 4 uses the Apache-2.0 license and can be embedded in commercially delivered products.

The memory mechanism is equally restrained: memories are created only when the user actively writes one, or accepts a Gemma suggestion and clicks "remember this", and are never generated automatically. Relevant memories are passed to Gemma as numbered untrusted data; Gemma must cite the memories it relies on, and the interface displays the cited sources; if a reply cites a memory that was not provided, the entire reply is discarded.

Ollama and local model deployment

Ollama is a local large-model runtime that provides a unified HTTP inference interface for model pulling, quantized loading and inference, allowing developers to run open-weight models such as Gemma and Llama on ordinary consumer hardware with a small amount of code. Pricor uses it to place Gemma 4 E4B inside the import workflow: the application calls the local inference endpoint directly, with no API key and no token fees, and data never leaves the machine. The trade-off is that inference speed and quality are limited by local hardware and quantization precision, so it is positioned as a fallback judge after Laya, not the sole decision-maker.

The benchmark does not support "fully automatic"

The benchmark published by the author in the repository contains only 29 held-out columns from two distributors and should be regarded as a sanity check rather than a leaderboard. The results are as follows: keyword/type heuristics correct 24/29 (82.8%), Laya zero-shot 18/29 (62.1%), Laya after fine-tuning 22/29 (75.9%), Gemma pure prompting 25/29 (86.2%).

In the full-table cascade, only 11 columns were resolved automatically (10 of them correctly), and 18 of the 29 columns still required user intervention. The author's attitude toward this is commendable: on this data, the application should ask questions. The limitations of the test are also honestly recorded—the thresholds were partly chosen based on synthetic validation data, the test set lacks certain roles, the heuristic rules were written after seeing the held-out headers, and two labels were corrected after the first run.

Flaws worth disclosing and next steps

The original article candidly lists two bugs. The first is percentage semantics: Excel stores a cell displayed as 21% as 0.21; once the number format is lost, a 21% VAT becomes 0.21%, and it can still compute a cost that looks plausible. The second is the second discount column: when a table has two independent discount columns, the plan builder uses only the first, which violates the application's own "never silent" rule; the fix is on the to-do list.

The backend test suite passes 1219 tests and the frontend 194, but this does not prove compatibility with every Excel file a supplier might produce. The author's next step is not to add features, but to conduct a supervised trial with retailers, comparing their existing import process using lists they already handle, observing where the confirmation step confuses people, and then judging how much ongoing support services are worth. Until then, the commercial hypothesis remains tentative.

Perhaps the lesson of Pricor is this: when AI handles data involving amounts and rules, "let the model understand, let deterministic code execute, let the user retain the final decision" is a more reliable division of labor than end-to-end automation.

One-line Summary

Pricor uses local models to understand the meaning of supplier table columns and a deterministic engine to precisely calculate net costs, while the user retains the final decision.

Paragraph Summary

Pricor is a local application that converts messy supplier Excel/CSV quotes into consistently structured, importable product records, outputting supplier code, description, net unit cost and currency while preserving row-level traceability. Its core division of labor is "model understands, engine calculates, user decides": a rule-based analyzer first identifies headers and number formats, the fine-tuned model Laya classifies column roles, uncertainties are handed to Gemma 4 E4B running locally via Ollama, and anything still uncertain is answered by the user. Price calculation is performed entirely by a deterministic engine with closed operations, and all intermediate steps are displayed as a receipt for verification. The benchmark published by the author covers only 29 held-out columns; in the cascade workflow, 18 columns still require user intervention, and the author candidly acknowledges flaws such as lost percentage formats and the second discount column being ignored.