- Recognition should deliver a checked accounting document, rather than just text extracted from a scan.
- Product matches, units, pack sizes, prices and VAT need review before final entry.
- Start with your documents and system version; verify the transfer method and draft support separately.
Supplier invoice recognition into accounting removes repeated typing. You upload a photograph, PDF or supplier spreadsheet; software extracts the details and line items, matches them to your product records and prepares the data for entry. A person checks uncertain results and approves them. For Syrve, Poster and BAS, we verify the transfer method and whether a draft can be saved on your particular version.
This workflow can be built around your documents and receiving rules. Its value appears in the accounting system: the correct product, quantity and purchase price reach the right stock location without someone retyping the invoice. Extracting readable text from a scan is only part of that result.
Where manual entry holds up purchasing records
The delivery is already in the kitchen, the paper invoice is with the receiving employee, a photograph is in a chat and accounts have a separate electronic copy. Recording the receipt means finding the document, choosing the supplier, locating every product in your own records and entering quantities and prices. Someone then has to reconcile the total and resolve differences.
Errors are not always typing mistakes. A supplier quotes a price per pack while your stock is measured in kilograms. An abbreviated description resembles a different ingredient. A discount appears below the table instead of on each line. Perfectly copied numbers can still produce an incorrect receipt when attached to the wrong product or unit.
Late entry also leaves costing reports incomplete. The owner can open a report without knowing whether the latest price increase has reached it. The useful improvement is a shorter path between receiving goods and having a checked stock receipt, rather than simply reading an image faster.
What can be read from paper, photographs, PDFs and Excel
A paper invoice must first be photographed or scanned. OCR means optical character recognition: turning an image of writing into text. Software then identifies the supplier, date, reference, product table and totals. AI can help interpret different layouts and suggest field values, but those suggestions still need checking.
A PDF may contain accessible digital text or only images of scanned pages. Digital text can be read without recognising the same characters again from a picture. Scanned PDFs follow the image route. All pages must remain together: a total on the final page may be essential to verifying the document.
An Excel file containing populated cells is better read as a spreadsheet. Photographing the screen would throw away useful structure. However, merged cells, multiple sheets, hidden rows and separate prices before and after discount still need rules. For each source, agree which columns represent the final values that should reach accounting.
A photograph should include the whole page without glare covering the numbers. Unreadable areas should be flagged for review or a replacement image requested. Software must not invent a plausible missing price. Agree supported formats and image quality requirements before development, so unsuitable documents do not become a surprise during daily use.
How an invoice moves from upload to approval
A practical workflow has a visible outcome at each step:
- Receive the document. Retain the original, check readability and group pages belonging to the same delivery. Check whether the document has already been processed.
- Extract the fields. Collect the supplier, date, reference, line items, quantities, units, prices, discounts, VAT and total where they appear in the source.
- Match your records. Find the corresponding supplier and product records, apply approved pack conversions and select the stock location.
- Prepare a review. Show the source beside the proposed result. Highlight new products, unusual prices and totals that do not reconcile.
- Transfer approved data. Create a draft in the accounting system if supported. Otherwise complete the review before writing, then show the document that was created.
A draft here means a record that should not yet have a final effect on accounting. How it can be saved depends on the application. If the available method immediately creates a stock receipt, approval must happen before that call. The approval button should reflect the actual point when data is written, so staff know what has already affected their records.
Why matching products is harder than reading numbers
Your product catalogue is the list of goods and ingredients used in your system. A supplier may describe the same items differently. Consider a hypothetical invoice saying “cooking cream” when your records contain several products with different fat contents and pack sizes. Similar wording does not prove that they are interchangeable. A wrong match changes stock records and dish costing.
Start with verified relationships: this supplier's product code, the approved item in your records, pack size and conversion rule. A barcode can help locate an item, but it does not by itself explain whether the quantity means individual units, packs or weight. Familiar wording from a new supplier still needs review before a relationship is saved.
An approved match can be reused for later documents. That does not make every future change safe to accept. A supplier might change pack weight or reuse an old code for a different product. Changes to the unit, packaging or description should bring the line back to a person. Otherwise an outdated rule can keep producing incorrect receipts without attracting attention.
Also agree what happens when no matching product exists. Automatically creating a new item for every unfamiliar name fills the catalogue with duplicates. A better approach is to suggest existing records and let the responsible employee choose one or deliberately create a new product. The catalogue stays manageable, and each decision remains explainable.
Check units, prices and VAT separately
Quantity and price must refer to the same unit. When a supplier sells a case but your stock is measured in kilograms, the case weight must be confirmed. For goods sold by actual weight, a standard conversion may not be appropriate. The reviewer needs to see the original quantity, the conversion rule and the quantity proposed for entry.
Then check whether prices include VAT, how discounts are allocated and whether additional charges appear. A line total must not be put into a unit price field. Check the arithmetic within lines, then reconcile their sum with the document total using agreed rounding rules. A mismatch should not be hidden by adjusting the final item simply to make the figures agree.
Your accountant determines the VAT treatment required by your accounting process. Software can transfer the stated values and check that amounts agree. It should not infer the applicable tax treatment from the appearance of a scan. Missing required information or multiple rates on one document need an explicit handling rule and review before entry.
Getting the result into Syrve, Poster or BAS
An API is a way for software systems to exchange data. This task needs access to the relevant product records and purchase receipt document. The existence of an API alone does not establish that access. We check your version, permissions and connection conditions before promising automatic entry into the destination system.
Syrve: establish the route to the stock document
Syrve publishes integration documentation, including Syrve Live API and Syrve POS API. An interface for tills or customer orders does not by itself establish a route for supplier invoices. For your installation, the stock accounting interface, permissions, licensing conditions and behaviour of the resulting document must be confirmed.
The manufacturer also describes its own PDF invoice recognition feature that creates a draft invoice. Check its availability and suitability for your documents first. If you need particular matching rules or another way of receiving documents, we can assess an addition. The actual write method and ability to save without posting need a test on your version, rather than a promise covering every Syrve installation.
Poster: create the supply after review
Poster's official documentation describes storage.createSupply, a method for creating a supply. Its inputs include the supplier, stock location, date and items with identifiers, quantities and prices. An optional packing parameter is also documented. The supplier's lines must therefore be matched to the relevant Poster records before submission.
The method description does not specify a draft mode. We do not assume one: review can take place in an intermediate screen, with the supply created only after approval. Tax fields and the settings your process needs require separate checks. After submission, verify the operation's success and the resulting document, rather than merely confirming that a request was sent.
BAS/1C: choose an import or exchange for the configuration
Official 1C platform documentation describes file exchange, HTTP services and exchange plans. An HTTP service lets applications send requests and data. An exchange plan defines the participants and the data involved in an exchange. These are development mechanisms, rather than a universal invoice import button available in every BAS configuration.
Check the configuration name and version, modifications, operating mode and permitted connection methods. A file for an existing import routine may be a suitable starting point. Other options include a dedicated service or configured exchange. Whether an unposted document can be created, and which fields it requires, must be tested with safe test data in the actual configuration.
Our 1C and BAS integration service describes data mapping, exchange checks and code handover. Supplier document recognition is assessed as a separate workflow around your accounting requirements. We do not present it as the same finished module for every system.
How accurate invoices support recipes and dish costing
A recipe specification, also called a technological card, records ingredients, quantities and preparation rules. Dish costing calculates ingredient costs using the prices recognised by your accounting process. Correctly recorded purchases provide inputs for that calculation. They do not automatically create a correct recipe or check the portion actually served in the kitchen.
If a receipt is assigned to the wrong product record, a recipe may keep using the old cost of the intended ingredient. Confusing kilograms with packs gives incorrect quantities and unit prices. The overall invoice total can still match when costs have been allocated to the wrong products. Checking totals alone is therefore insufficient.
Food cost percentage expresses ingredient costs as a share of sales; agree the precise calculation used in your report. Purchase prices support cost calculations, while actual consumption also depends on stock balances, write-offs and stocktakes. The full cost of running the business includes more than ingredients. Labour and other expenses need their own treatment.
What stays human, and what happens when a connection fails
A person confirms the goods received, resolves disagreements with the supplier and approves new matches. A scan cannot prove that the stated quantity actually arrived or that its quality was acceptable. Recognition helps record the receiving decision. Responsibility for accepting the physical delivery remains with the team that sees and checks it.
The agreed solution needs clear states: awaiting review, needs correction, ready to transfer or already recorded. If access to accounting expires, the invoice should stay in a queue with an explanation for the responsible employee. An application update or changed supplier layout also needs checking, even if the integration code itself has not changed.
A particularly difficult failure happens when the destination accepts a document but the response is lost. Blindly retrying can create another receipt. First reconcile the destination using the saved relationship or document details; only then allow another attempt. A corrected invoice must also not silently overwrite an approved record. Recovery rules belong in the workflow agreed before launch.
What determines the development scope
The estimate depends on the rules involved. A repeated spreadsheet with approved product matches needs different work from photographs sent by several suppliers. Existing mappings, available write methods and exception handling all matter. Page count alone does not describe the difficulty.
Separate initial development from running costs, which may include recognition, required system access and maintenance after updates. Check third-party terms before estimating. Also agree who can view purchase prices, where documents are stored and whether an external recognition provider may receive them. Define retention and deletion before sending real files.
Assign someone to handle the error queue. Instructions should explain how to check status, correct a line and resume safely. If staff enter a stalled delivery manually, a delayed automatic retry must not create it again. The recovery procedure should account for that situation as well as a straightforward connection failure.
Start with your accounting process and measure the benefit
For an initial discussion, provide the system name, version and anonymised sample documents. Include an ordinary invoice and a difficult example: different packaging, an unclear photograph, a discount or a new product. Show how those details should appear in accounting. Passwords are not needed in the first message; first establish the task and possible connection route.
Agree the smallest useful result: specified formats, required fields, matching rules and an approval step. This fits our custom software development around your process. Additional channels, other document types and wider exchanges can follow once the first working route has been checked and its benefit is visible to the people using it.
During a pilot, a small trial of the workflow, compare complete manual entry time with uploading, reviewing and correcting the proposed result. Count unreadable lines, incorrect matches and duplicate documents. Check the destination: stock location, product, quantity, price, VAT and document state. An attractive extraction preview is not enough to accept a workflow whose promised result is an accurate purchase receipt.
If an existing import or available tool already meets the requirement, start there. Custom work makes sense where particular matching rules, unusual documents or manual transfers remain. Our business AI assistant services and publicly documented integrations provide context for discussing scope. We can build this workflow around your needs; an estimate starts with your documents and a check of the destination system.
FAQ
What is supplier invoice recognition?
It extracts document details and line items from photographs, scans or electronic files. Entry into accounting also requires matching your product records, checking units, prices and VAT, and human approval. Extracted text alone is not a correctly recorded purchase receipt.
Can supplier invoices be read from photographs, PDFs and Excel?
A workflow can be built for these formats. Photographs and scanned PDFs need image recognition; digital PDFs can provide readable text; Excel is better processed as spreadsheet data. Supported formats and quality requirements are checked against your samples. Unreadable fields are referred for review.
Can recognised invoices be entered into Syrve, Poster or BAS automatically?
The write method depends on your version and permissions. Poster documents supply creation through storage.createSupply but does not describe a draft mode there. For Syrve, the stock document route and availability of built-in recognition need checking. For BAS, we assess an import, HTTP service or configured exchange for your configuration.
Does invoice recognition still need human approval?
Yes. A responsible person confirms goods received, new matches, pack sizes, disputed prices and tax fields before final entry or posting. If the destination does not support drafts, review takes place before transfer. Error-free recognition is not promised.
How does invoice recognition help dish costing?
A correct receipt connects the purchase price and quantity to the intended ingredient, providing inputs for costing against a recipe specification. It does not automatically correct the recipe. Portions, losses, write-offs and stock balances still need their own records and checks.
