AI-based item master matching is the process of finding a match between a supplier’s line item and an existing product record in an accounting or ERP system. The model helps parse abbreviations, product names, and specifications, while the matching decision relies on identifiers, required attributes, and verifiable rules. The result should include the matched record, the reasons for the match, and a verification status.
This task comes up for distributors, manufacturers, e-commerce retailers, and procurement teams. In one system, the item is called “Oil Filter X-120,” while in another it is “Filter Element X120, 12 pcs/pack.” Similar names do not prove that a document can be processed or a replacement ordered.
Key principle: the system must distinguish exact match, acceptable equivalent, new item, and insufficient data. If everything is reduced to “96% similarity,” the employee will not understand which action is allowed.
Prepared on September 8, 2026, using AI and verification against primary sources. It is intended for catalog owners, procurement leaders, and IT teams. Examples and calculations are for training purposes only; this article describes how to design matching, not how to certify equipment interchangeability.
Contents
- Different catalog tasks
- When AI is needed
- Data preparation
- Matching algorithm
- Packaging example
- 1C integration
- Quality control
- Economics
- Frequently asked questions
Matching, normalization, and deduplication: what’s the difference
Normalization converts a description into a consistent structure: brand, model, size, material, unit of measure, packaging. It makes records easier to compare, but it does not establish that they are identical. Two strings can be perfectly normalized and still describe different products.
Matching links an external item to an internal identifier. Deduplication finds multiple records for the same product within a catalog. Equivalent selection solves a different problem: it determines an acceptable substitute based on usage requirements. These processes can be technically combined, but mixing up their outcomes is risky.
| Task | Input | Result | Who owns the rule |
|---|---|---|---|
| Normalization | Free-form name | Structured attributes | Reference data owner |
| Matching | Supplier item | Internal ID and basis for the link | Procurement and accounting |
| Deduplication | Internal records | Candidates for merge | Master data owner |
| Equivalent selection | Product requirements | Substitute candidates | Technical specialist |
For example, two records with different codes may refer to the same product but have movement history in different warehouses. You cannot delete one just because the model found a match. Transferring inventory balances and document links is a separate controlled operation.
For a project, it helps to define the goal without using the vague word “cleanup”: “reduce manual selection of the internal product record when importing price lists.” This wording makes it possible to measure results and keep responsibilities clearly separated.
When AI is needed and when a reference table is enough
Start with stable identifiers and already confirmed links. If the supplier sends the same SKUs repeatedly, a cross-reference table may solve most of the task. Using a model for every recurring document increases cost and creates new answer variations without additional value.
In 1C-EDO documentation it describes saving item mappings for later document completion. So before development begins, it is worth checking which links your configuration has already accumulated instead of building them from scratch.
The 1C:Nomenclature service also supports working with descriptions, attributes, and matching items from counterparties’ documents. The existence of such a service does not mean it covers a specific industry catalog: that must be checked against your items and software versions.
AI becomes useful where identifiers are missing, names differ significantly, or important parameters are hidden in the text. For example, size is listed inside a comment, material is abbreviated, and the brand is misspelled. The model can suggest a structured representation and a list of candidates, which then undergo review.
A sensible order of selection is: built-in accounting system logic, a matching dictionary, normalization rules, candidate search, and only then a model for ambiguous descriptions. The pilot should show the contribution of each component. If a complex neural network does not improve results compared with a simple SKU search, its use is not justified.
What data to prepare before development
Export a limited product group with internal codes and current attributes. The external price list should be kept in its original form: manually renaming lines before testing will hide the real complexity of the task. Save the supplier, file date, and line number so the result can be verified.
For each group, define the required attributes. For fasteners, these may include size, thread, material, and strength class; for electronics, model, housing, and electrical specifications; for packaging, dimensions, material, and quantity. You cannot use one universal checklist for all categories.
Agree on which source is considered authoritative in the event of a conflict. A manufacturer’s technical datasheet, a verified product record, and a shortened name from a price list have different evidentiary weight. If a key attribute is missing from the record, the correct action is to request it, not to automatically trust the most detailed text.
| Registry field | Purpose |
|---|---|
| Supplier ID and supplier SKU | To distinguish identical codes from different suppliers |
| Original name | To verify transformations |
| Internal ID | To reference a specific record |
| Unit and quantity in package | To correctly recalculate quantity and price |
| Critical attributes | To filter out incompatible products |
| Source version and date | To detect changes |
| Decision status and reviewer | To understand whether the link can be applied |
Separately collect known incorrect pairs. For example, nearly identical names of two parts with different operating voltages. Such pairs are especially useful for testing: a system that recognizes obvious matches well may make mistakes precisely on risky near-matches.
How to build a matching algorithm
Step 1. Check exact identifiers
Start with a confirmed link of “supplier + SKU,” the manufacturer’s code, and applicable standard identifiers. GTIN in the GS1 system is designed to identify trade items. At the same time, having a number that looks like a barcode does not prove the supplier data is correct.
Check the format, source, and packaging level. You cannot compare a case-level identifier with an individual item identifier while ignoring the shipment structure. If the same code is accompanied by incompatible attributes, the conflict should be shown to an employee rather than resolved automatically in favor of the code.
Step 2. Normalize descriptions
Clean up technical noise: extra spaces, repeated separators, and different ways of writing units. Lowercasing is usually safe for search, but keep the original string. Changing characters in a SKU requires caution: Latin C and Cyrillic S may be a typing error, or they may belong to different codes.
Extract characteristics into separate fields and preserve the source of each value. If the model read “20” as a length, the fragment that states this should be visible. If the unit is missing, the number remains an incomplete attribute rather than automatically turning into 20 millimeters.
Step 3. Find Multiple Candidates
Candidate search narrows a large catalog down to a list of possible matches. Keyword and part-number search preserve exact matches well, while semantic search helps when wording differs. Vector text representation captures semantic similarity, but it does not establish technical compatibility.
In Elastic's hybrid search documentation it describes combining different search approaches. For product catalogs, this is a useful architectural idea: do not sacrifice an exact part number for semantic similarity. The specific search engine should be chosen based on volume, infrastructure, and test results.
Step 4. Apply Mandatory Constraints
Before selecting a result, filter out incompatible categories, sizes, materials, and other critical attributes. If the request requires a specific grade of steel, a nice-looking match to a product name made of another material should not be automatically entered.
Technically, constraints can be implemented through filters on structured attributes. For example, Qdrant documents filtering by metadata. The mere presence of a filter does not solve the problem of incomplete data: an unknown value must be handled separately from a confirmed match.
Step 5. Explain the Decision and Define the Action
The final result should answer three questions: which item was chosen, based on which attributes, and what action is allowed. Instead of one percentage, show the matching IDs, verified characteristics, contradictions, and missing data.
Use four statuses: “confirmed match,” “candidate for review,” “no match found,” and “insufficient data.” Store the analog as a separate link type. This lets an employee understand the decision without reading a long model explanation.
Training Example: Similar Name, Different Products
The supplier sent the line “Filter X120, pack of 12, 6 packs.” In the internal catalog there are “Filter X-120, each,” “Filter X-120A, each,” and “Filter Set X-120, 10 pcs.” The names are similar, but the letter suffix and packaging require separate verification.
If it is confirmed that X120 and X-120 are the same manufacturer code, and the package contains 12 identical units, six packages correspond to 72 units. This is a deterministic recalculation after the relationship has been confirmed. The model should not invent a package factor from a similar product name on its own.
| Candidate | Basis | Decision |
|---|---|---|
| X-120, each | Confirmed code match, recalculation required | Possible match after packaging verification |
| X-120A, each | Model suffix differs | Do not treat as an exact match |
| X-120 set, 10 pcs | Different trade unit composition | Check the contents, do not substitute automatically |
Assume the supplier's price is listed per package: 2,400 rubles. At 12 units, the calculated unit price is 200 rubles, and the cost of six packages is 14,400 rubles. If the price is mistakenly treated as a per-unit price, the total will be overstated by a factor of 12. That is why packaging is part of the data model, not decorative text in the name.
Consider the opposite situation: the number of units per package is missing. Even with an exact model match, the system must ask for clarification. Automatically looking up the number in an old price list is acceptable only as a hint with the source date, since packaging may have changed.
How to Connect the Result to 1C
At the start of rollout, save the result to a staging register instead of changing the main master data right away. The employee sees the supplier line, candidates, an explanation, and a confirm button. The confirmed link becomes available for future imports, taking version and scope into account.
The register should account for both the organization and the supplier. Item code “1001” for two counterparties may refer to different products. Substituting a link without supplier context leads to errors that are hard to notice because the item card formally exists and the document posts successfully.
Integration issues are covered in detail in the article on integrating AI with 1C. For a specific project, you need to check the configuration, available interfaces, exchange volume, and the service account's permissions. There is no universal command that can safely modify any 1C database.
Before each write, check whether the item card is still current: it may have been marked for deletion, merged, or changed after export. Re-delivering the result should not create a new link. The log should store the old and new values, the basis, the user, and the time of application.
Do not enable automatic product creation in the first stage by default. The “not found” status may indicate a search error or an incomplete description. A new item card should pass its own checks for mandatory attributes and duplicates; otherwise, automation will only speed up the accumulation of junk data.
How to Check Matching Quality
Build a benchmark from confirmed pairs and clearly different products. Separate the samples by supplier, category, and time period. If identical lines from the same price list are used both in tuning and in validation, the result will be inflated: the system has already seen almost the same example.
Measure candidate search and the final decision separately. If the correct item card is not in the candidate list, improving the final prompt will not help. If the card is found but the system chooses a neighboring variant, the problem lies in comparison and constraints.
Useful metrics include the share of cases with the correct candidate in the list, the accuracy of automatically accepted matches, the automation rate, and the average manual review time. For critical categories, count errors separately: one wrong substitution matters more than ten extra employee questions.
Training test: out of 500 lines, the system matched 300 automatically, and 297 of those were correct. The accuracy of automatic decisions is 99%, and automation coverage is 60%. The remaining 200 lines are not automatically errors: they may include new products and valid rejections due to insufficient data.
This result still does not prove that the project is acceptable. You need to analyze the three incorrect matches: are they cosmetic differences in the description or a different product? The release threshold is chosen based on cost and the consequences of errors, not on how attractive the overall percentage looks.
Why You Should Not Trust a Single Confidence Score
The model can confidently explain the wrong pair. The similarity score from vector search, the confidence of text recognition, and the probability of a correct business decision are different values. They should not be combined into a single quality metric without validation.
If the input consists of scans, errors occur even before matching. Microsoft Document Intelligence separately addresses the interpretation of accuracy and confidence. For a project, this means you need your own set of field checks and thresholds that match the company's documents.
Calibrate the rules on a holdout set. For a group with reliable item codes, one workflow may work; for free-form product names, another may be better. A threshold value without a description of the sample, category, and acceptable error is practically useless for acceptance testing.
How to Evaluate the Economics
Let’s take a hypothetical flow of 8,000 rows per month. At 45 seconds of manual matching per row, the workload comes to 100 hours. If the fully loaded hourly cost is 800 rubles, the monetary equivalent of the work is 80,000 rubles per month.
Assume that after the pilot, 65% of rows are processed automatically, and the remaining 2,800 are checked in 30 seconds each. That is 23.3 hours. Add 10 hours for sample control and reference data maintenance: in total, about 33.3 hours, or 26,667 rubles. With hypothetical technical costs of 15,000 rubles, the total recurring cost is about 41,667 rubles.
The difference from the original process is roughly 38,333 rubles per month. If one-time investment is 300,000 rubles in this example, a simple payback calculation gives about 7.8 months. These figures are needed to demonstrate the formula; they are not the service price or a forecast of results for another company.
Now reduce the flow to 2,000 rows with the same hypothetical overhead costs. The economics become much weaker: reference data maintenance and infrastructure do not scale down strictly in proportion to volume. So it is worth evaluating whether a separate system, a built-in 1C feature, or a limited operator assistant is more cost-effective.
Add the expected cost of incorrect matches, returns, and document corrections to the financial model. If automation saves hours but increases expensive errors, the project may not be worthwhile despite faster processing. Separately account for the impact of improving the catalog for search and analytics, but do not book it as revenue without measurement.
How to Organize the Pilot and Ongoing Support
Start with one category that has clear attributes and an employee who can confirm the ground truth. Agree on statuses and prepare a set of difficult pairs. Then compare a simple mapping table, text search, and an AI-based option on the same data.
The next stage is recommendation mode. The system suggests a match, and the employee confirms or rejects it with a reason. Reasons should be structured: different packaging, wrong model, insufficient data, item out of stock. This provides material for improving the rules, not just a set of negative ratings.
Enable automatic posting only for verified classes. Route a new supplier through enhanced review first. Changes in price list format, packaging composition, and reference data should trigger a review of previously confirmed matches.
Support should include a master data owner, version history, deviation monitoring, and a way to reverse an incorrect match. You need a report showing which documents used the disputed match. Removing an entry from the dictionary does not retroactively fix transactions that have already been completed.
Before acceptance, check file re-import, a change to a previously confirmed item code, a missing critical attribute, a new category, and a 1C write failure. The pilot result is not only the match rate, but also reliable handling of exceptions.
Frequently Asked Questions
Can you just upload two Excel files into a neural network?
For a small preliminary comparison, yes, if the data processing mode is acceptable. For regular work, you will need value sources, stable identifiers, packaging rules, logs, and result validation. One file with the model’s answer does not replace that process.
Do you need a fine-tuned model?
Not necessarily. Start with reference data quality, search, and constraints. Fine-tuning should be considered after analyzing recurring errors and having labeled examples. It will not fix a missing size or an incorrect packaging coefficient in the source data.
Can AI choose substitutes on its own?
It can prepare candidates. Whether a substitute is acceptable depends on the use case and mandatory characteristics, so the rules should be approved by a subject matter expert. The “equivalent” relationship should be stored separately from the “same item” relationship.
What should you do if the products have no item codes?
Extract characteristics and search for candidates based on a combination of attributes. If information is insufficient, leave the decision for review. Missing identifiers increase the demand for high-quality descriptions, but they do not justify guessing.
Can duplicates be merged automatically in 1C?
Finding candidates for merging is acceptable as a separate step. The merge itself affects documents, balances, and analytics, so it requires a dedicated process and rollback capability. It should not be treated as a routine extension of price-list matching.
How do you know when it is time to expand automation?
When the agreed criteria are consistently met on new data, the review queue is manageable, and the cost of exceptions has been measured. It is better to expand by category and supplier while keeping the option to return to manual approval.
How AIrassvet Helps with Product Master Data
Within business process automation and LLM integration projects, AIrassvet can structure the work around data preparation, validation of extracted attributes, and feeding approved results into the accounting process.
The first step is to choose a product group and collect verified correct and incorrect pairs. This makes it possible to determine where rules are enough and where AI is needed, and to align the pilot criteria. Discuss the project.
What the result should look like
A useful matching system produces a verifiable link to a specific product card and explains where uncertainty remains. It preserves units, packaging, and version differences, and reuses approved decisions. Start with the quality of the reference data and the rules for one category: they determine whether AI becomes an operator assistant or a source of new catalog errors.