Using AI in 1C: purchasing, item catalog and orders in Trade Management, Integrated Automation and ERP

For trading and manufacturing companies, using AI in 1C, the accounting and ERP platform most Russian companies run on, means connecting a model to the data in 1C:Trade Management (UT), 1C:Integrated Automation (KA) or 1C:ERP. The model reads master data, documents and transaction history, and prepares drafts for the buyer, the sales manager and the catalog owner. On the operations side, it can be given four processes: demand forecasting and supplier orders, cleaning up duplicates in the item catalog, matching supplier items to your own at goods receipt, and parsing incoming customer orders into a “Customer Order” document. The model should not post orders, merge records or confirm mappings on its own. It handles repetitive work reliably and makes confident mistakes wherever the company has its own master data, purchasing rules and exceptions.

Below, for each of the four processes, we look at what the model does reliably, where it gets things wrong, and why without access to your master data and internal procedures the result does not match how you actually work. We also show what 1C services already cover and where they hit the limits of the standard configuration. The accounting side, the question of where the data goes, and responsibility for errors are covered briefly here, with links to separate articles. At the end: what to prepare before you start, and why an off-the-shelf assistant covers only part of the job. Code generation for 1C developers is outside the scope of this article.

Which operational tasks can AI take on in UT, KA and 1C:ERP?

AI takes on tasks that involve many similar decisions, have a history of correct answers, and where an error can be caught before the document is posted. On the operations side there are four such processes, and in each one the model prepares a draft: a forecast and supplier order, a list of likely duplicates, a proposed mapping, a filled-in customer order. The decision stays with the employee responsible for that area.

Order processing is the most common target of automation in Russian companies. According to a study by SberAnalytics and Sber Business Soft (November 2025, 559 respondents), 70% of companies automate document flow and order processing, and 25% automate sales. Among automation tools, 39% of companies use AI agents and assistants, and 24% use ERP.

How does AI forecast demand and prepare a supplier order?

The model calculates a sales forecast from history and proposes a quantity to purchase, and the buyer reviews and posts the order. For forecasting, 1C has an official cloud service, and it connects to UT, KA and ERP as a standard feature. Turning a forecast into a supplier order only works through purchasing rules, and every company has its own.

According to the description of 1C:Sales Forecasting on the 1C:ITS portal, it is available in 1C:Trade Management from version 11.5.19, and in 1C:Integrated Automation and 1C:ERP from version 2.5.19. The service takes sales data from the database, selects a model automatically and produces a forecast one to thirty periods ahead: by day, week or month. The listed models include moving average, a seasonal model, exponential smoothing, gradient boosting and recurrent neural networks. Forecasts are broken down by item, variant, warehouse or store, and customer. As additional inputs, the service can take into account the business calendar and discounts, and the finished forecast can be adjusted manually, for example for a planned advertising campaign.

Calculations run in the 1C cloud, and according to the company, it does not share data with third parties during forecasting. The service is paid. The service page on the 1C:Trade Management website lists a free thirty-day trial plan and paid quota-based plans, and the software must be under official support.

Where the model gets things wrong shows up in the sales history:

• Stockouts in the history. An item was out of stock for three weeks, and sales in those weeks are zero. The model sees a drop in demand where there was demand, and underestimates the forecast.
• New items. There is no history, or it is shorter than a season. The forecast is built from comparable items, and it is the buyer who knows which item counts as comparable.
• Promotions and one-off deals. One large tender or a clearance sale pushes the series up. If they aren't flagged, the model expects them to repeat.
• Duplicate items. Sales of one product are spread across three records, and each one gets a forecast three times lower than the real figure.

A forecast answers how much you will sell. A supplier order answers a different question: how much to buy and when, given stock on hand, reservations, goods in transit, lead time, minimum order quantity, pack multiples and the money available for purchasing. These rules live in buyers' heads and in the replenishment settings in 1C. If they aren't written down, the model will propose an order that adds up mathematically and fails the supplier's terms. Why stock in the database diverges from what's on the shelf, and how that breaks any purchasing calculation, is covered in the article on inventory tracking.

Can AI clean up duplicates in the item catalog?

It can find likely duplicates and explain why it considers the records the same. The catalog owner should do the merging. The standard duplicate search in 1C works by field-comparison rules, while the model compares records by meaning and finds pairs that the rules miss.

UT, KA and ERP include a standard “Find and Delete Duplicates” tool. It compares selected fields for an exact match or by similar words, and it is good at catching records created twice under the same name. Records spelled differently often slip past it: “Angle 50x50x5 St3”, “Steel angle 50505” and “Equal angle 50 mm” are three different products as far as it is concerned. A language model reads such names the way a person does and groups them as likely duplicates.

Typical findings from this kind of search:

• Different ways of writing dimensions. “50x50”, “50*50”, “50 x 50”, with and without spaces.
• The supplier's name instead of your own. The record was created at goods receipt from someone else's document, and your own record for the same product sits right next to it.
• Part number in the name or not. One record has the manufacturer's part number at the start of the name, the other doesn't.
• A variant as a separate record. Color or size has been set up as separate items, even though the catalog has variants for exactly this.

The model gets things wrong on items that differ by a single parameter, abbreviated in the name or stored in a separate field. Steel grade, GOST versus TU (a national standard versus a manufacturer's specification), bar length, bolt strength class: for the warehouse these are different products at different prices, while for the model they are almost identical strings. That is why each proposed pair comes with an explanation and the fields of both records, and a person makes the decision.

Merging duplicates should be treated as irreversible. Document references, stock, prices and supplier item mappings move to the main record, and untangling them six months later is nearly impossible. Before launching the model, the company writes down naming rules and decides what is set up as a variant and what as a separate record. Without these rules, the model will propose merges by its own logic, a little differently each time.

How does AI match supplier items to your own at goods receipt?

For each line of the supplier's document, the model proposes an item from your catalog and converts packs into your units. The storekeeper or operator confirms, and the confirmed mapping is saved. The hardest part is the first match: a new supplier, new items, someone else's names.

1C has been saving mappings for a long time. When documents are loaded via EDI (legally binding electronic document exchange between companies in Russia), the software stores which of your items corresponds to the supplier's item and fills it in automatically on the next delivery. The 1C:Primary Document Recognition service does the same for scans and files. According to an article by 1C experts on buh.ru (October 30, 2025), it matches suppliers and items to database objects, and if a name in the document differs from the catalog, it suggests an option. After one or two confirmations, the choice is remembered. The service works in UT, KA, 1C:ERP and other 1C products.

The model is useful where there is no saved mapping yet. It reads the line's name, manufacturer part number, unit and price, and looks for your item by meaning rather than by matching characters. A new supplier sends its first delivery note with two hundred lines, and today each one is matched by hand. The model proposes an option for every line, and the person only has to check.

Where the model gets things wrong at goods receipt:

• Substitutes. The supplier replaced a product with an equivalent from another manufacturer. The model finds a similar item and doesn't know that the substitution wasn't agreed under the contract.
• Similar part numbers. Different manufacturers use identical or nearly identical part numbers for different products.
• Units of measure. The document says “box”, you use “piece”, and the item record doesn't say how many pieces are in a box. The conversion comes out wrong, and stock is off by the pack multiple.
• An error in the supplier's document. If the supplier shipped the wrong item, the model will carry that into your database if it matches by name rather than by what is actually on the shelf.

Hence the rule: a low-confidence suggestion from the model goes to a person, and a confirmed mapping is written to the catalog and from then on works without the model. The accuracy ceiling for recognition and the payback threshold by document volume are covered in the article on primary document recognition in 1C.

How does AI turn a customer's email into a “Customer Order”?

The model reads the email, attachment or messenger message, finds the customer, items, quantities and dates, and creates a draft “Customer Order” document in 1C. The sales manager reviews it before reservation and shipment. The hardest parts here are matching the customer's names to your catalog and keeping the model from filling in the price.

Orders arrive in every possible form. Text in the body of an email, an Excel spreadsheet in the customer's own format, a PDF from their accounting system, a photo of a handwritten request, a message in Telegram. The model pulls the same things out of all of them: the customer and contact person, items, quantities, units, the requested date and delivery address. It matches items to your catalog using that customer's order history. If they have been writing “roofing screw 4.8x35” for years, the model already knows which record that refers to.

The model does not make up prices, discounts or payment terms. In UT, KA and ERP these come from customer agreements and contracts according to your accounting rules, and the draft order is filled in exactly as if the manager had created it by hand. A model that takes the price from the email or from memory will sooner or later ship goods at someone else's price list.

Where the model gets things wrong on orders:

• Vague requests. “Same as last time, just more nails” requires knowing the previous order and deciding how much “more” means.
• Packs instead of units. The customer writes “10 pk.”, while the database price is per unit.
• Changes to an old order. A reply in an email thread changes an order that has already been accepted, and the model creates a new one.
• No such item. The customer asks for a product that isn't in your range, and the model picks the closest similar one instead of asking the manager.

Any off-the-shelf tool for this task knows the standard “Customer Order” document. Your modifications to the order, your approval procedure, your reservation rules and the channels through which orders arrive are unknown to it, and all of that has to be configured for your database. How the whole path from request to payment is structured, and where money gets lost along it, is covered in the article “Sales automation”.

What can off-the-shelf 1C services do, and where do they hit their limits?

Off-the-shelf 1C services cover sales forecasting and saving item mappings in the standard configuration. For semantic duplicate search and parsing orders from emails, we did not find official services for UT, KA and ERP while preparing this article; these are built for the specific database. Some of what is written about “AI in 1C” has nothing to do with the operations side at all.

1C:Naparnik is described on its own page as a development assistant included with 1C:EDT 2025 and later. It is what most articles ranking for “AI in 1C” are actually talking about, but it gives buyers and sales managers nothing.

Where off-the-shelf solutions stop working:

• A modified configuration. Your own order fields, your own statuses, your own reservation procedure. A standard solution will fill in the standard fields and leave yours empty.
• Your own purchasing rules. The service will calculate a forecast, but delivery schedules, minimum order quantities and purchasing budget limits by supplier are known only to your buyer.
• Multiple systems. Orders come from a CRM or a customer portal, the warehouse runs on a WMS, and 1C receives the data via exchange. The answer to “why wasn't the order reserved” lies at the junction between systems. How such setups are structured is covered in the article on systems integration.
• Updates. A modification built for one configuration version has to be re-tested after every update, and the more custom changes the database has, the more often something breaks.

Where does the data go, and who is responsible for the model's mistakes?

The data goes wherever the model runs, and responsibility for the result lies with the same people who were responsible for purchasing, the catalog and orders before. On the operations side this is handled the same way as in accounting: the model proposes, a person posts, and this division is enforced through the permissions on the model's user account.

The operations database holds purchase prices, supplier terms, margins and customer contacts. That is commercial confidential information and personal data, and it must not be sent to a public foreign chatbot. Options for hosting the model, from a Russian vendor's cloud to the company's own infrastructure, are covered in the article “Neural networks without data leaks”. Who is responsible for an error AI introduced into the books, and how to set up the assistant's permissions, is covered in detail in the article on AI in 1C:Accounting.

Buyers draw this line themselves. According to a survey of users of the TenderPro e-procurement platform (CNews, July 20, 2026), more than 75% of companies do not consider handing the full procurement cycle over to AI, from analyzing bids to choosing a supplier and signing the contract. The main barriers are the risk of losing control (73%), legal risks (62%) and concerns about data leaks (56%). Companies do trust AI with supporting tasks, data processing and document preparation.

On the operations side, this translates into four restrictions for the model's user account:

1. Do not post supplier or customer orders. The model creates a draft, a person posts it.
2. Do not merge item records. The model proposes pairs, the catalog owner merges them.
3. Do not change prices, agreements or supplier terms. The model only reads this data.
4. Do not work without a log. What the model read, what it proposed and who confirmed it is written to a log; otherwise, a quarter later, there is no way to trace where an error in the database came from.

Where to start?

With one of the four processes and a description of what a correct result looks like. It is easiest to start with a process that has high volume and where the reference is already in the database: confirmed customer orders, mappings for major suppliers, purchases of fast-moving items. This description immediately shows what a 1C service will cover and what will have to be built for your database.

1. A process with a reference. What counts as a correct result: a supplier order the buyer would have posted themselves, a customer order in the right status, a decision on a pair of duplicates. A few dozen such examples from your database.
2. Clean master data. An item catalog without duplicates, packs and units in the item records, customers and suppliers without duplicates. The model works with what's in the database, and on messy master data it will make confident mistakes.
3. Written rules. Lead times and minimum order quantities by supplier, item naming rules, the procedure for approving orders and reservations. Everything that currently lives in employees' heads.
4. A decision on data. Which parts of the database the model sees, which it never sees (purchase prices, margins), and where it runs: a Russian vendor's cloud or the company's own infrastructure. The business makes the decision, and the contractor turns it into permissions.
5. Permissions and a log. A separate user account without the rights to post, merge records or change prices, plus an action log. For official 1C services, the software must be under official support.
6. A test copy and integrations. A copy of the database where the model is tested before launch, and a list of the systems 1C exchanges data with: email, messengers, EDI, CRM, warehouse.
7. An owner after launch and ongoing support. An employee who looks after master data, rules and the quality of suggestions, and a support contract. The product range, suppliers and configuration change, and without an owner, a quarter later the assistant is working by outdated rules.

The company handles the first three on its own, and those alone strongly affect the quality of the answers. The other four show what the project price is made of: how many modifications the database has, which data is off-limits, which systems need to be connected. The general framework of stages and budgets is laid out in the article on AI adoption stages and costs.

Off-the-shelf or a system built around your process?

An off-the-shelf solution covers the standard part: calculating a sales forecast, remembering a supplier item mapping, filling in an order in the standard form. Companies diverge below that level, because their procedures, master data, access rights and exceptions are all their own.

At the outset, the operations side looks similar for everyone: buy, receive, sell, ship. For a small trading company with standard UT and a tidy catalog, the forecasting service and the built-in mapping memory are often enough for a long time.

The differences start with the rules. One company buys once a week on the supplier's schedule, another buys against customer orders, a third keeps safety stock for fast-moving items and buys the rest per project. One sets up color as a variant, another as a separate record. Some customers send orders in their own Excel format, others write in a messenger, and afterwards the order is approved by the commercial director. An off-the-shelf assistant knows the standard data model, but it doesn't know your purchasing rules, your catalog or your approval procedure. We covered the choice between an off-the-shelf solution and a system built around your process separately — your own system or off-the-shelf.

INCUBE AI works under contract, keeps data in Russia and builds the assistant around your setup in UT, KA or ERP. It works with your master data and modifications, receives permissions according to your role matrix, keeps an action log and is connected to email, messengers, CRM and the warehouse. After launch, the system stays under support. You can see what such a setup looks like on a real project in the project for a wholesale and manufacturing company. There, orders from email and messengers are collected into a single queue, each order immediately sees stock and places a reservation, shortages on orders turn into purchase and production requests, and items, stock, shipments and payments are synchronized with 1C. If your buyers and sales managers are drowning in retyping and reconciliation, tell us about the task: we'll take one process, run it on a copy of your database and tell you plainly where a 1C service is enough and where the assistant will have to be built for you.

Sources and links

• 1C:Sales Forecasting, 1C:ITS portal — available in UT from version 11.5.19, in KA and ERP from version 2.5.19, and in 1C:ERP Holding Management from version 3.2.3. Models: moving average, seasonal model, exponential smoothing, gradient boosting, recurrent neural networks. Horizon of one to thirty periods, interval of a day, week or month. Breakdowns: item, variant, warehouse or store, customer. Additional inputs: business calendar and discounts; the forecast can be adjusted manually. According to 1C, no data is shared with third parties during forecasting.
• 1C:Sales Forecasting, 1C:Trade Management website — free thirty-day trial plan, paid quota-based plans, calculations in the cloud; the software must be under official support.
• buh.ru, October 30, 2025: how to automate primary document entry with 1C:Primary Document Recognition — automatic matching of suppliers and items to database objects, remembering the choice after one or two confirmations, works in UT, KA, ERP and other 1C products.
• 1C:Naparnik — a development assistant for 1C, included with 1C:EDT 2025 and later.
• CNews, January 22, 2026: study by SberAnalytics and Sber Business Soft — November 2025, 559 respondents. 70% of companies automate document flow and order processing, 25% automate sales. Among automation tools, 39% use AI agents and assistants, 24% use ERP.
• CNews, July 20, 2026: survey of TenderPro e-procurement platform users on AI in procurement — more than 75% of companies do not consider handing the full procurement cycle over to AI; barriers: risk of losing control 73%, legal risks 62%, concerns about data leaks 56%.