◆IKORG
Русский

← Practice · 22 October 2026

AI for 1C: how to turn scans into trip sheets

How to reconstruct trip sheets from driver reports: reading scans, checking arithmetic and linking transport orders. Pilot results and the tasks that still need a person.

10 min read1C

The paperwork survived, but the database records were lost. A transport company faced this problem: five legal entities, 1C on its own server, and records that needed rebuilding after a failure. The surviving sources included driver reports for May–October, about 1,300 scanned pages. These had to be turned into trip sheets and linked to transport orders in the production database.

Reading the handwriting might seem like the main task. But every line we read brings more work: interpreting the values, checking the arithmetic, finding the order and creating a document without duplicates. The Claude Code AI agent handles this under the supervision of the owner of IKORG studio. A person decides whether to import the data.

The pilot produced 6 trip sheets containing 38 orders: 21 were found in the database and linked, and 17 were created from the reports because there were no suitable matches in the database. All fields could be read, and the arithmetic was checked. So far, this is the result for a verified subset: the rest of the archive still needs processing and checking.

Why reconstruct trip sheets from scans

Ransomware encrypted the company’s server along with the backup drive installed inside it. A new server was set up from scratch, and the production 1C database was restored from an old copy dating to roughly the end of April. Data for May–September was missing. The accounting records were also rebuilt from sales ledgers, text recognized from scans and electronic document exchange.

In the industry-specific configuration used by the carrier, work revolved around orders, trip sheets and service completion certificates. Restoring accounting documents was only part of the task: we also needed to restore the links the company used every day.

About 2,500 sales records from the accounting system were converted into orders, service completion certificates and VAT invoices in the production database. Driver reports provided a different source: data for trip sheets and links to existing orders. Here, we had to make sure that processing a scan did not recreate an order that had already been restored.

Note the periods: the database gap covers May–September, while the report archive covers May–October. Some information on the pages could already be in 1C. That is why we compare each scan with the database contents before importing it.

There is no decryptor, and the encrypted files were not decrypted. The records were rebuilt from surviving sources. The full story is described in the case study on restoring 1C records after ransomware; here, we will look at the work with driver reports.

How document scan recognition works in 1C

The path from an image to a trip sheet has several steps. The AI reads the page, extracts data, checks the arithmetic and matches rows to orders. Documents are then created from the prepared data.

Each step answers its own question: what is written here, do the values add up, which order does this row belong to, and how do we save the result in the records? If we mix everything together, a recognition error goes straight into the database, now looking like a respectable document.

The intermediate result therefore needs to be available for review: first we look at what was read and what it was linked to, then we create the trip sheet.

Read the scan and extract the data

A person looks at the report as a whole: they see where an entry begins, understand what a signature refers to and which rows form a table. Automated processing needs to preserve this structure too.

A continuous block of text is not enough. We need to separate the values and identify their purpose: trip details must stay in their own row. If the words and numbers are recognized but the relationships between them are lost, the report will have to be put back together.

In this case, a separate Claude instance read and checked the pages, rather than a dedicated recognition program. It converted scans of driver reports into data for further processing. There are still several steps before this becomes a 1C document: even a perfectly legible row first needs to be checked and matched against the records.

Check the arithmetic

A number read with confidence can still be wrong. Where values are linked by a calculation, we check whether the arithmetic adds up after recognition.

A discrepancy helps identify a problem, but does not always reveal its source: the AI may have made a mistake, or the report’s author may have. We cannot pick a convenient number just to get a tidy total. Arithmetic is a checker here, not a literary editor.

The arithmetic was checked in the pilot. We need to repeat this check for subsequent reports and pass uncertain values to a person along with the original scan.

Find the order and create the trip sheet

Now we need to link what we have read to the records. The database already contains orders, including those restored from the accounting system. The task is to find the right one and link it to the trip sheet.

Similar text helps with the search, but the match to the trip is what matters. In this case, an order was considered a match if it belonged to the same legal entity, had the same counterparty and amount, and had a loading date within three days.

A matching order was linked to the trip sheet, and its old number from the driver’s report was added to the comment. A new order was created only when there was no suitable match: the trip existed on paper, but the order was missing from the database. The manager approved this rule.

A trip sheet is saved once all its rows have been resolved. If even one remains uncertain, the entire document waits, and the uncertain rows go to a person for review. This ensures that only fully resolved trip sheets enter the database.

What the 1C trip sheet pilot showed

The pilot’s results can be counted:

We completed the full path from page to document: the data read from the scans was used to create trip sheets, link existing orders and create missing ones.

All fields in the selected reports could be read. However, a legible value can be misinterpreted, and a document whose arithmetic adds up can be linked to the wrong order. That is why verification is needed even when recognition goes smoothly.

About 1,300 pages is the size of the original archive. There is no confirmed count of processed pages here. The pilot shows that the method works on the verified sample; it is too early to use it to estimate accuracy across the entire archive or a completion date.

Next, we need to work through the remaining reports with the same checks and handle exceptions separately.

Where a person is needed when AI works with 1C

Automated reading reduces retyping. People still make the decisions that require understanding the data and the consequences of changing the database.

Spot checks. We compare the original page with the result: were the values read correctly, are all rows present, and was the right order selected? Arithmetic alone cannot check this: the data may add up perfectly while belonging to a different trip.

Uncertain fields. We flag any value that cannot be determined confidently for review. There were no such fields in the pilot, but other scans are still ahead. Even if the system has no doubts, comparison with the source remains necessary.

The import decision. The manager needs to see which documents will be created and which records they will be linked to. Checking how a scan was read and authorizing a database change are separate decisions.

All work in this case was carried out remotely, and every action is logged. Destructive actions require the manager’s decision. This also applies to subsequent cleanup: finding a duplicate does not give the agent permission to delete data on its own.

The log lets us trace how a document was reconstructed and examine the result. The contents still need checking: a neat record of an operation does not make the operation itself correct.

Why we cannot simply import all the scans into 1C

Even a perfectly read report can produce a duplicate: the corresponding document may already exist or may be created alongside the recovery work. Recognition quality cannot fix this.

In this case, numbering caused problems. A new number is generated using “maximum plus one” within a given prefix and year, so simply moving the counter forward will not work. Importing restored and new documents at the same time produced duplicate numbers. Later, when exporting to the accounting system, new documents with those numbers overwrote the restored ones.

We looked for duplicate content using a straightforward rule: one vehicle with one driver cannot make two identical trips on the same date. The matching copies and duplicates we found were marked for deletion. This is a separate records management task.

Before a bulk import, we need to establish what is already in the database, how numbers are assigned and what will happen during data exchange with the accounting system. Otherwise, automation will enthusiastically increase the reviewer’s workload.

Details are in the article on numbering, duplicate documents and bank statements during 1C recovery. For scans, the rule is simple: we assess whether the source can be read and, separately, whether the database is ready to accept the result.

How AI differs from ordinary OCR

OCR recognizes characters in an image and converts visible text into text data. That is enough, for example, to make a document searchable.

With trip sheets, the work continues: we need to preserve the report’s structure, understand the purpose of its values, check calculations and match entries to 1C objects. Having recognized text alone does not complete these tasks.

The boundary between tools can be blurred: recognition systems may also include additional document processing. We should choose based on results with our own materials and the checks available before writing to the database.

Here, the required output is a trip sheet with linked orders. If a tool only reads the page well, data conversion and finding links remain separate tasks.

AI makes mistakes too. Its ability to interpret page structure helps, but we still check arithmetic, links and duplicates.

Will source document recognition in standard 1C work for this

The feature name “source document recognition” sounds suitable. But the name does not tell us whether the tool can handle driver reports and reconstruct the required part of the records.

This case uses an industry-specific configuration for a carrier: we need trip sheets linked to existing orders. We assess any ready-made solution across the entire process, from the scan to the document and its links.

We need to test standard 1C capabilities on the specific task. There is no basis for promising success or rejecting existing tools in advance: first, we establish which documents the solution supports and what it creates in the database being used.

When choosing trip sheet software, we need to check how it works with our source material and existing records. A name in a feature description will not link orders, and buying software does not solve the matching task by itself.

Which AI works best with 1C

There was no comparative test in this case, so we cannot produce an AI ranking from it. Claude Code carries out the work under the studio owner’s supervision. What has been confirmed is the pilot result on specific reports and a production database.

It is more useful to choose using our own documents. Can the tool read a page, preserve its structure, show the data for verification and prepare the required object? What will it do with an ambiguous row?

Managing changes is a separate question. The manager needs to see the result before import, and database actions must remain auditable. A confident tone in chat is not a qualification in recordkeeping. AI generally finds confidence easier than being error-free.

Start with samples and a task in 1C. Compare results on the same material, including errors and cases that required human involvement.

What other paperwork can be processed in a similar way

A similar approach can be used to process scans of reports, service completion certificates, delivery notes and other documents containing information needed for recordkeeping. These are possible tasks; the pilot described here worked with driver reports.

For each type of paperwork, we need to define the output. In some cases, a table for review will be enough; in others, links to existing documents are needed. Poor source quality or ambiguous content may require manual review.

The sequence is the same: read the source, extract the data, check it and decide whether to import it. But the rules for a new type of paperwork need separate testing: a driver report cannot serve as a template for every situation.

Frequently asked questions

Can scans be imported directly into trip sheets?

In this case, data processing, arithmetic checks and a search for existing orders stand between the scan and the trip sheet. An image saved in the database does not restore the records by itself.

Do driver reports need to be retyped manually?

In the pilot, AI processed data from scans to create documents. A person checks the result, resolves uncertain fields and decides whether to import the data.

Did AI recognize the entire archive of 1,300 pages?

The confirmed result is the pilot: 6 trip sheets with 38 orders, of which 21 were found in the database and 17 were created from the reports. About 1,300 pages is the size of the original archive. There is no information confirming that processing has been completed.

What should we do if a number has been read but the calculation does not add up?

Return to the scan and check the values. We cannot automatically change a number to make the total match: the error may be in the recognition or in the report itself.

Can this method decrypt files after a malware attack?

No. There is no decryptor in this case. The records were reconstructed from other sources: surviving accounting records and scans of driver reports.

Want to process your paperwork the same way?

At IKORG, we work on tasks where information has survived in scans but is needed in operational records. We start with sample documents and the desired result: what to extract, what to link it to in 1C and what a person needs to check. This lets us determine the processing procedure.

If reports have piled up or you need to reconstruct documents from surviving sources, write to us. We will examine the task, define the checks and prepare a clear result for the import decision. The studio owner supervises the AI agent’s work; destructive actions require the manager’s decision.