How to automate supplier price-list updates with review controls

Define the import contract

An import contract states what a file means and which changes it may make. Agree it with the person who owns supplier costs. Record these fields before building the import.

Keep item codes as text. Preserve leading zeros and punctuation unless an approved rule changes them. Keep the original value beside any normalized value. Do not silently turn an empty cost into zero.

CSV is not one completely uniform format. Delimiters, quotation rules, and other details can differ between sources. Python's CSV documentation describes these differences. Store the expected format for each supplier. Stop when the headers or structure change unexpectedly.

Use a staged process with a preview

1. Register the file. Save the original in controlled storage. Record its supplier, receipt time, effective date, import ID, and file fingerprint. A fingerprint helps detect the same file again. It does not prove that two different files describe different business changes.
2. Parse into staging. Staging is a temporary set of proposed records. It does not change the live catalog. Store source row numbers so a reviewer can find the original evidence.
3. Validate required fields. Check identifiers, currency, costs, quantity basis, and dates. Reject values that cannot be interpreted under the supplier's rules. Treat zero, negative, and unusually large values as separate exception types.
4. Check key uniqueness. If one supplier item should have one active price per purchasing unit and effective date, enforce that definition. Tiered prices need quantity-break fields in the key. Do not let duplicate rows silently multiply matches.
5. Match to approved products. Use the reviewed supplier-to-product cross-reference. Separate matched, unmatched, and conflicting rows. Suggested matches may help a reviewer, but they must not become automatic cost updates.
6. Calculate comparable costs. Compare the same currency and quantity basis. Keep source cost and normalized unit cost separate. Use a defined decimal and rounding policy.
7. Produce a change preview. Show the old and proposed values, quantity basis, percent change, effective date, source row, and reason for any hold. Group changes into eligible, held, unchanged, and new-product rows.
8. Approve and apply a bounded batch. Bind approval to the exact batch and staged revision. Record the source file, mapping version, rule version, proposed values, approver, and expected prior destination version or values. If a source row, mapping, rule, or proposed amount changes, invalidate approval and show a new preview. Before writing, compare the destination with the expected prior version or values. Hold a changed destination for a fresh comparison. Enforce that comparison in the same destination update where supported. A separate read followed by an unconditional write can still overwrite an intervening change. Save prior values. Give each applied update a stable action identity so a retry cannot create a second change record or repeat downstream actions.
9. Reconcile the result. Compare approved changes with confirmed destination updates. Report failures and unknown outcomes separately. Keep held rows visible until a named person resolves them.

A supported conditional update can protect against a stale preview. For example, HTTP If-Match can require the destination's resource version to match before applying a change. Confirm that the destination supports the required condition. If it does not, coordinate exclusive updates or hold the change for a controlled manual process.

A join is the operation that links supplier rows to catalog rows. The pandas merge API can check expected key relationships and mark unmatched rows. It also warns that null keys can match each other. Reject missing match keys before joining. These are implementation controls, not proof that the product identity is correct.

See ZenOut's seller and supplier systems service if you need this process connected to your current files and catalog. Start with one supplier and a reviewable change report.

A fictional example: a case price is not a unit price

All products and amounts below are fictional. They are not customer data or a promised outcome. The previous approved price for supplier item SUP-041 is $30.00 per case of six units. Its comparable unit cost is $5.00.

The 15% threshold is an example policy, not an industry standard. Choose thresholds based on the products, normal changes, and consequences of error. Use separate rules for increases, decreases, and absolute currency changes when needed.

Decimal arithmetic can preserve decimal monetary values and apply explicit rounding rules. Python's decimal documentation explains its arithmetic and rounding controls. The business must still define whether to round source costs, unit costs, or final totals. Keep sufficient precision for the chosen calculation.

A unit cost also does not equal a fully loaded cost. Shipping, duties, payment costs, and other charges may be separate. Store their assumptions separately. Do not label a simple supplier-price comparison as a complete profit calculation.

Define exception behavior before the first live import

A product disappears from the next file

A missing row does not automatically mean discontinued or free. Check whether the file is a full snapshot or a change list. Preserve the existing cost until the documented absence rule applies. Mark old prices as stale when their validity rule requires it.

The file contains two prices for one item

Check effective dates, quantity breaks, locations, and purchasing units. The rows may be valid alternatives. If they conflict under the same key, hold them. Do not choose the last row merely because it appears later in the file.

An older file arrives after a newer file

Use its approved effective date and version rule. Receipt time alone does not establish business priority. Show conflicts to a reviewer. A future-dated price must not replace today's price before its approved start date.

A PDF or AI extraction supplies the values

Keep the source page or cell reference. Treat extracted values as proposals. Require review for product identity, quantity basis, and monetary fields until an agreed evaluation shows which cases can pass automatically. Never let an instruction inside a supplier document change the import rules or destination permissions.

Only some approved updates succeed

Keep a per-row result. Retry only unresolved updates after checking the destination. If the team requires all-or-nothing publication, apply updates through a destination mechanism that supports that behavior. A local database transaction does not automatically cover another service.

An approved price was wrong

Restore a previous value only after checking whether a later valid change replaced it. Record a corrective change and its reason. Reversing a cost record does not reverse orders or other actions already taken from it.

Check an import before release

Use a test catalog and deliberately include bad rows. Keep the expected decisions beside the input file.

• Reimport the same file. Confirm that it produces no repeated live update.
• Send a file with a changed header. Confirm that parsing stops or requests review.
• Include missing keys, repeated keys, and an unknown item code. Confirm that they do not become guessed matches.
• Change pack size, currency, and effective date. Confirm that each follows its own rule.
• Include blank, zero, negative, and very large costs. Confirm that their handling is explicit.
• Check the fictional 30-to-36 case example. Confirm a 20% unit-cost increase.
• Apply a newer file, then an older one. Confirm that the older file cannot silently overwrite it.
• Approve a staged batch, then edit a proposed amount or its mapping. Confirm that approval becomes invalid and no changed proposal is applied without a new preview and approval.
• Change a destination cost after preview but before apply. Confirm that the stale proposal is held. Repeat the check with a change that occurs immediately before the write. Confirm that the supported destination condition prevents an overwrite.
• Interrupt a destination update. Confirm that the result can be reconciled before retry.
• Compare input row counts with matched, unmatched, conflicting, and rejected counts. Confirm that no source row disappears without a reason.
• Restore a mistaken test change. Confirm that its history remains available.

Copy the supplier import checklist

Supplier and authorized source:
Original file and import ID:
Expected headers, delimiter, and encoding:
Full snapshot or change list:
Product and purchasing-unit key:
Required fields and missing-value rules:
Approved cross-reference version:
Quantity and pack-size rules:
Currency, tax, and included-charge basis:
Decimal precision and rounding policy:
Effective-date and older-file rules:
Review thresholds and exception owner:
Proposed / eligible / held / unchanged counts:
Approver, approved batch, and exact staged revision:
Approved source, mapping, rule, and proposed-value versions:
Expected prior destination version or values:
Stale-preview hold and conditional-write control:
Approval invalidation after any relevant edit:
Per-row action identity:
Confirmed / failed / unknown update counts:
Recovery and correction procedure:
Test evidence and unresolved questions:

Start with a change report

Run the import without writing to the live catalog first. Review several representative files and resolve the exceptions. Use those decisions to refine the rules. Only then enable the specific updates your team can verify and recover.

For the broader project decision, read the AI implementation guide. Use duplicate-action controls for retries. If the review queue has outgrown its workbook, read when to build an internal tool.

Book a conversation about a supplier import. Bring redacted before-and-after files and the rules your team currently uses to approve a cost change.