Answer in brief
Half of the closing-documents conveyor's 2-4 day estimate goes into template layout, and the recogniser's exception path is what separates a useful table from a clean table full of wrong numbers.
Half of a two-to-four-day estimate is template layout
The VIT Market catalogue lists “Conveyor of closing documents: invoice, act, UPD in one click” with a duration written as “⏱ 2-4 days, half of which is polishing the layout of templates to meet accounting requirements”. That second clause is unusual for a price list, because it admits where the time actually goes. Generating a document from a database row is a morning of work. The other half of the estimate is spent making the printed page look like the page the accounting department already accepts without comment.
This is not a rounding detail, it is the shape of the entire job. A closing document is a legal object whose acceptability is decided almost entirely by its surface: where the counterparty block sits, the order of the columns, whether the total is repeated in words underneath the figures, whether the numbering continues the series the company has been using since January. None of that is business logic. All of it is formatting, and every item on that list is enough on its own to get a document sent back.
Teams that budget for this work as “a PDF generator” are budgeting for the easy half and will be surprised by the other one. They discover fairly quickly that the accountant does not reject documents for wrong arithmetic, because arithmetic is the part software gets right on the first attempt and keeps right forever. Documents come back because the VAT line is phrased in a way the counterparty's own bookkeeping cannot ingest, or because the signature block sits where a scanner will crop it.
So the honest way to read the two-to-four-day band is as two jobs of roughly equal size wearing one price tag. The first job is mechanical and finishes on schedule. The second is a negotiation with people who have been rejecting documents for years and can tell you exactly what a correct one looks like, but usually only after they have seen an incorrect one. Budgeting a day for that conversation is not padding, it is the part that determines whether anything ships.
What “one click” actually compresses
The catalogue is specific about where the document comes from: “From a line in a table or a transaction in CRM, an invoice and act are automatically generated according to a proprietary template, in PDF, with the correct numbering and amount in words, and immediately sent to the client’s email.” Read that sentence as five separate manual steps that used to be performed by one person switching between four windows, and the phrase “one click” stops sounding like marketing and starts sounding like a specification.
Numbering is the first of the five and the one most often waved through. A serial number is shared state. Two people issuing invoices at the same moment must not receive the same number, a document that is generated for preview and never sent has to either consume a number or explicitly not consume one, and a cancelled document leaves a hole that somebody will eventually have to explain. Each of those is a decision the buyer should make deliberately rather than inherit from a default.
The amount in words is the second, and it is the field that quietly destroys trust. It has to agree with the figure to the last kopeck, follow the grammatical rules of the language it is printed in, and handle the awkward cases: zero kopecks, round thousands, sums that cross a grammatical boundary. A generator that writes this line wrong once will be checked by hand forever afterwards, which returns the accountant to exactly the position the service was bought to remove them from.
The fifth step, “immediately sent to the client’s email”, is where the conveyor stops being an internal convenience and becomes an external commitment. Once documents leave automatically, the send itself needs a record: which version of which template went to which address at which minute, and what happens when the address bounces. Without that record, an argument about whether a document was ever sent becomes unwinnable, and the conveyor has moved a problem rather than removed one.
The bottleneck the description names out loud
The description for the conveyor ends with a flat sentence: “The accountant ceases to be a bottleneck.” It is worth being precise about what that claims, because it is not a claim that the accountant is slow. In most companies the accountant is fast and the queue is still long, because closing documents arrive at the accountant serially, in a batch, at the end of a period, from people who each believe their own request is small.
A bottleneck of that kind has a characteristic signature: the work is not evenly spread, it is a spike. Nothing needs an invoice for three weeks and then twenty things need one on the same afternoon, usually the afternoon before a deadline. Adding capacity does not fix a spike, because the capacity sits idle for three weeks. Removing the serialisation does fix it, which is what generating from the CRM row rather than from a request in a chat window accomplishes.
There is a second effect that rarely appears in the business case and matters more than the time saved. When issuing a document is instant, people issue documents at the moment the commercial event happens rather than at the moment they get around to it. Payment terms start earlier, disputes surface while the details are still fresh, and the gap between “work delivered” and “document issued” stops being a place where revenue quietly ages.
The catalogue marks this service “Advanced” in its difficulty field, and given the above that grading is about coordination rather than code. The hard part is not the generator. The hard part is agreeing, across sales, delivery and accounting, on which event in the CRM is the one that authorises a document to exist, and then holding that agreement steady once the button starts working.
The other side of the desk: documents that arrive rather than leave
The outbound problem is bounded because you control the template. The inbound problem is not bounded at all, and that is the whole reason the second service in this pair carries a different price. The catalogue lists “Recognition of invoices, invoices and contracts into structured data” in the same “Document flow” category, also graded “Advanced”, at “$1 000 - $3 500” or “80 000 - 250 000 ₽”, with a duration of “⏱ 10-18 working days”.
Its description states the contract plainly: “You send a PDF or a scan - the output is neat JSON or a line in 1C/Excel: counterparty, INN, number, date, positions, amounts, VAT. Replaces the accountant's manual input and eliminates typing errors.” Every noun in that field list is a place where an inbound document from an unfamiliar counterparty can differ from every inbound document you have seen before, and none of those counterparties will be adjusting their layout to suit you.
This is why the same formatting problem reappears with the sign reversed. On the outbound side you spend half your estimate deciding what a correct page looks like. On the inbound side you spend most of your estimate discovering how many incorrect-looking pages are nevertheless valid: the scan rotated four degrees, the table that breaks across two pages, the supplier who puts VAT in a footnote, the contract whose key terms live in an appendix that was photographed separately.
The practical consequence is that inbound recognition cannot be specified from a description of the ideal document. It can only be specified from a pile of real ones, including the ugly ones, which is why the sensible first act of this project is collecting that pile rather than choosing a model. The ten-to-eighteen-working-day band assumes such a pile exists; a project that starts by asking for it will spend part of that band waiting.
The exception path is the design decision, not the accuracy number
A recogniser that returns a value for every field on every document will always produce a clean table. Cleanliness and correctness are unrelated properties. A table with no blanks in it looks finished, gets exported, gets summed, and gets used for a payment run, and nothing in its appearance distinguishes a total assembled from correctly read invoices from a total assembled from a few confidently misread ones. This is the failure mode worth designing against, because it is silent.
The alternative is to give the system three outcomes instead of two. Accepted means the fields were read and the internal checks agree. Rejected means the document could not be processed at all, which is loud and therefore harmless. Held means the document was read but something does not reconcile, and it waits in a queue for a person. The third state is the one that costs money to build and the one that makes the other two trustworthy.
What sends a document into the held state should be checks the reader can explain, not an opaque score. The line items do not sum to the stated total. The VAT figure does not correspond to the declared rate. The INN fails its checksum. The counterparty name and the INN point at different organisations. The invoice date is later than the date it arrived. Each of these is a rule a human accountant already applies in their head, and each is cheap to encode.
Once the held state exists, the honest measure of the project changes shape. The question stops being “how accurate is it” and becomes “what share of documents reach a person, and is the reason they reached that person always legible”. A system that sets documents aside and attaches a specific complaint to each one is doing its job. A system that routes nothing to anyone is either extraordinary or lying, and you cannot tell which from the table alone.
Which of the seven fields are allowed to be guessed
The catalogue names the output fields explicitly: counterparty, INN, number, date, positions, amounts, VAT. Treating those seven as equally important is the most common design error, because the cost of an error differs by an order of magnitude across the list. Sorting them by consequence before development starts is a half-hour conversation that changes what gets built, and it is a conversation the buyer is better placed to lead than the developer.
Amounts and INN are hard-fail fields. A wrong amount produces a wrong payment, and a wrong INN attaches a real document to the wrong legal entity, which is the kind of error that is discovered by a tax authority rather than by you. Neither should ever be accepted on a low-confidence read. If the system cannot verify them against something else on the page, the document goes to the held queue and a person settles it with one look at the page.
Number and date are recoverable. A misread invoice number is annoying and gets caught the first time somebody searches for it; a misread date shifts a document into the wrong period and gets caught at close. These fields deserve validation, but not a blocking one. They are good candidates for being read, flagged with low confidence, and corrected in bulk later rather than one at a time in a queue.
Positions, the line items, are where the interesting errors hide, because the failure is structural rather than textual. A row that wraps onto a second line can be read as two rows. A subtotal in the middle of a long table can be read as a product. A page break can drop a row entirely. None of these produce a value that looks wrong on inspection, which is exactly why the sum-to-total check earns its place as the cheapest structural guard in the system.
Ten to eighteen working days, and what actually fills them
The duration field for the recognition service says “⏱ 10-18 working days”, roughly two to nearly four calendar weeks. It is tempting to assume the width of that band reflects model selection or infrastructure. It does not. Both ends of the band use the same components; the difference between the fast end and the slow end is how many distinct document layouts the buyer's inbound stream actually contains and how quickly examples of them can be produced.
A company that receives documents from twelve regular suppliers in stable formats sits at the short end. A company that receives documents from two hundred counterparties, including scans made with a phone at an angle and contracts assembled from three different templates, sits at the long end and should plan for it. Nobody can tell which one you are from a description of your industry. It takes an hour of looking through a mailbox, and that hour is worth spending before signing anything.
The remaining time goes into the parts that are invisible in a demo: the mapping into 1C or Excel columns that actually exist in your system rather than the ones the developer assumed, the handling of duplicates when the same invoice arrives twice by two channels, the behaviour when a document is a scan of a scan, and the review interface that the held queue needs in order to be used rather than ignored.
Setting expectations from that reading is straightforward. If you want the short end of the band, arrive with fifty to a hundred real documents chosen to include your worst cases, a written statement of which fields are hard-fail, and a named person who is allowed to decide what a correct mapping looks like. If you arrive without those, the band will not be shorter, the discovery will simply happen inside it.
Two price bands in the same category, pricing two different unknowns
Placed side by side, the two services in this pair share a category and a difficulty grade and almost nothing else. The conveyor is listed at “$250 - $900” or “20 000 - 70 000 ₽” over 2-4 days. The recogniser is listed at “$1 000 - $3 500” or “80 000 - 250 000 ₽” over 10-18 working days. Both carry the difficulty grade “Advanced”, which is the catalogue telling you that neither is a weekend script.
What separates them is not sophistication, it is who controls the input. On the outbound side the input is your own database and your own template, so the unknown is a matter of taste and internal approval, and taste can be settled in a meeting. On the inbound side the input is produced by hundreds of organisations who have never heard of your project, so the unknown is empirical and can only be settled by looking at documents.
That distinction explains why the widths of the two ranges behave differently too. The conveyor's range is mostly about how many document types and templates you need and how strict your accounting department is. The recogniser's range is about the diversity of your counterparties and the quality of their scanning. One is a scope question you can answer today from memory; the other is a measurement you have to take.
It also suggests a sequencing rule that costs nothing to follow. Buy the side that is bleeding. If your team is late issuing documents and chasing signatures, the conveyor pays first and pays quickly. If your team is retyping supplier invoices into an accounting system and finding transposed digits at close, the recogniser is the one to fund, and the conveyor can wait for the next quarter without anything getting worse.
Arithmetic you can run at your own desk before requesting a quote
What follows is an example of a calculation, not a measurement of anything, and the numbers in it are yours to supply rather than ours to assert. Count the closing documents your company issued last month; the figure is in your accounting system and takes two minutes to find. Time yourself producing one by hand, honestly, including the switching between windows and the re-reading of the counterparty details. Multiply. That product is the outbound number the conveyor is competing with.
Do the same in the other direction. Count the supplier invoices and delivery notes that were retyped into your system last month, and time one honest retyping including the verification pass that a careful person does afterwards. Multiply again. That second product is the inbound number. Whichever of the two products comes out larger is a better guide to which service to buy first than any argument about which technology is more interesting, and the value of the exercise is in the comparison rather than in either figure on its own.
Then add the number that is easy to forget: the count of documents that came back for correction, from either direction, and the elapsed calendar time between the first send and the accepted version. Reissues are cheap in minutes and expensive in days, and days are what payment terms are denominated in. A document rejected on Friday and corrected on Monday has cost a weekend of float regardless of how quickly the correction itself was made.
None of these three figures is a benchmark and none of them appears in the catalogue. They are worth computing anyway, because they convert an abstract question about automation into a specific one about your own month, and because arriving at a scoping conversation with them makes the difference between discussing a price range and discussing your price inside it.
What to send a contractor before day one
For the conveyor, send the templates you already use, in their final approved form, plus one example of each document type filled in with real values. Then send something more useful than either: the last three documents that came back from a counterparty or from your own accounting department with a complaint attached, and the complaint. Those three pages define the acceptance criteria more precisely than any specification, and they compress the half of the estimate that goes into layout.
Also send the numbering rules as they are actually practised, not as they are written down. Which series exist, where the counter resets, what happens to cancelled numbers, whether previews consume the sequence, and who is allowed to issue a document out of order. These rules usually live in one person's memory. Extracting them in advance is cheaper than discovering them on the day the conveyor issues its first duplicate number.
For the recogniser, send documents rather than descriptions, and choose the pile deliberately. Include the cleanest supplier you have and the worst one. Include a multi-page invoice, a scan that is rotated or shadowed, a contract with an appendix, and at least one document from a counterparty whose formatting nobody in the office likes. Fifty representative documents are worth more than a five-page requirements memo, and they take less time to gather.
Finally, decide before the project starts who owns the held queue. It needs a named person, a place it lives, and an expectation about how quickly it is emptied, because a review queue that nobody has been made responsible for silently converts into the clean-table-full-of-wrong-numbers problem, and it does so sooner than anyone expects. The exception path is a process decision that software supports, and it is the one part of this pair of projects that cannot be delivered by a contractor.
Questions and answers
How much does automating invoices, acts and UPD cost, and how long does it take?
The VIT Market catalogue prices “Conveyor of closing documents: invoice, act, UPD in one click” at $250 - $900, or 20 000 - 70 000 ₽, with a duration of “2-4 days, half of which is polishing the layout of templates to meet accounting requirements”. That published split is the useful part: plan for roughly half the engagement to be spent on template layout and accounting approval rather than on the generator itself.
Why is document recognition so much more expensive than document generation?
Because you control one input and not the other. The catalogue lists the conveyor at $250 - $900 over 2-4 days and “Recognition of invoices, invoices and contracts into structured data” at $1 000 - $3 500, or 80 000 - 250 000 ₽, over 10-18 working days. Generating uses your own template and your own database; recognising has to cope with layouts produced by every counterparty who has ever sent you a scan.
What data do I actually get back from invoice recognition?
The catalogue states the output fields exactly: “neat JSON or a line in 1C/Excel: counterparty, INN, number, date, positions, amounts, VAT”, from an input that is a PDF or a scan. Treat those seven as unequal in risk: amounts and INN should never be accepted on a low-confidence read, while number and date are recoverable errors that can be flagged and corrected in bulk.
Do I need both services, or should I start with one?
Start with whichever direction currently costs you more. Both services sit in the catalogue's “Document flow” category and both carry the difficulty grade “Advanced”, but the conveyor finishes in 2-4 days and the recogniser takes 10-18 working days, so the outbound side also delivers a result far sooner. Fund the recogniser first only if your team is retyping supplier documents by hand today.