Invoice templates in Bitrix24 diverge from deal data
A manager opens a deal card and clicks "Print invoice" — but the document receives something different from what they see on screen.
Details remain from the previous counterparty, the bank account and KPP fields come through empty, and sometimes another legal entity from the directory is inserted.
The discrepancy between deal data and invoice surfaces later in accounting, at the payment stage, when trust in the document is already undermined.
The cause is more often not the print form itself, but how it is assembled. The template reads values from card fields directly, without checking whether they are filled in or which organization they belong to.
If the company has several legal entities or the counterparty changed its details, old values remain in linked fields and are inserted again. Manual entry of details in such a scheme becomes a mandatory step — and it gets skipped under a flow of requests.
The second part of the breakdown is the moment of printing. Printing an invoice from the card is launched from the deal, while the data for the document lies in linked entities: company, contact, details.
While the links are not synchronized, the template silently inserts whatever it found — hence empty fields in one invoice and someone else's data in another. Invoice issuance errors are almost always reproduced on the same deal, so they are caught after sending, not before.
We break down how this is closed: where the template takes values from, what is checked before output, and how to remove manual entry of details from the process.
What changes in the department's work after auto-filling details
Before auto-filling, the invoice is assembled manually: details are copied from the card, an email, or a previous document, and KPP and bank account are verified by eye.
One document takes five to fifteen minutes, and with a flow of dozens of invoices this is a noticeable part of the department's working day. An error in one character returns the document for reissue along with repeated approval.
After setup, details are inserted into the template from the counterparty card, and the manager only has to check the line items and terms. Invoice preparation takes one to two minutes, and manual operations are reduced to selecting a template and a final check.
The speed of invoice issuance stops depending on the accounting workload and on who exactly prepares the document.
A class of errors that returned most often goes away separately: outdated details after a bank change, mixed-up fields, typos in the name. The share of returns for reissue falls to isolated cases, and each return is a payment delay and extra correspondence with the client.
Template version control closes the second half of the task: edits are made in one place, a version is recorded for the template, and an accidental "custom" edit does not spread across documents.
When the form or tax rate changes, one template is updated — and all subsequent invoices come out in the new form, while the previous version remains available for rollback.
The effect can be checked using three metrics before and after: average time to prepare a document, share of invoices returned for reissue, and number of manual corrections to details per month. If two out of three do not move, then auto-filling is only partially configured.
Methods of generating invoices: comparison of approaches
In Bitrix24, an invoice can be assembled in four different ways, and the choice is determined not by template convenience but by where the details come from and who is responsible for their currency.
While there is one organization and data changes once a year, a standard template is enough; with the appearance of branches, different contracts, and payment terms, substitution rules and external print forms are connected.
| Option | When it fits | Where it hits a wall |
|---|---|---|
| Standard template | One organization, details are stable | Fields are edited manually in each deal, there is no logic for VAT, deferral, or currency |
| Template with substitution rules | Several organizations, different contracts and terms | Rules live inside the template: any edit goes through a developer, and change history is not kept |
| External print form | A non-standard look is needed: blocks, appendices, signatures | Platform updates break bindings, debugging happens on live deals, preview is limited |
| Separate document preparation service | High volume, several systems, end-to-end numbering | Synchronization of directories and access rights is needed; a delay appears between the deal and the finished file |
In practice, integration limitations set the ceiling for any of the options. If company and contact details in the CRM are incomplete or are not updated from the accounting system, the invoice will go out with an outdated address or code — and no template will fix that.
Therefore, we first describe data sources and reconciliation rules, and only then choose the invoice form.
Implementation procedure: from directory audit to handover
The order of work here is more important than speed: an error in details is not cosmetic but an invoice that the counterparty will not accept and that accounting will process manually.
Therefore, we first describe the data, then the substitution logic, and only then touch the production environment — testing runs on a database copy and on real documents.
- Audit of directories and fields. We go through counterparties, contracts, items, and bank details: we look for duplicates, empty TINs and KPPs, discrepancies between legal and actual addresses, fields without a default value. The result is a list of data "holes": without it, any automation replicates the error across all invoices.
- Field substitution scheme. We fix the map: which template attribute is taken from which source and with what priority — counterparty card, contract, our company's details, manual edit. Separately, we describe conditional blocks, VAT, and the behavior of optional fields when the source is empty.
- Assembly of the print form. We design the layout with mandatory and conditional sections, line items, signatures, and logo, and set up versioning — so that an edit can be rolled back and compared with the previous revision.
- Access rights setup. We separate roles: who generates the invoice, who changes the template, who edits directories. Changing details after the document is generated is restricted — otherwise auto-filling loses its point.
- Testing on test documents. We run a sample of real cases: legal entity, individual entrepreneur, non-resident, with and without VAT, partial shipment. We compare amounts, tax, details, and print appearance against reference invoices.
- Trial run and transfer. We move settings and the template from the copy to the production environment, show accounting the invoice generation scenario, and review typical discrepancies.
- Handover with a regulation. We provide the description of the substitution scheme, the rights matrix, instructions for editing the layout, and the procedure for actions when details change.
After handover, the template lives without us: a change in details in the card is immediately reflected in new invoices, and editing the layout does not require code intervention.
Package of documents, settings, and rules delivered
After project completion, the client is left not with a folder of files but with a working environment: templates, detail substitution rules, separation of rights, and an edit procedure.
All of this is described so that a new employee or contractor can understand it without the solution's author. Below is exactly what is included in the package.
- Set of invoice templates. Print forms for each legal entity, direction, and settlement currency, with placeholders instead of hard-coded details. They are edited through a visual editor without code changes — marketing or accounting can change the header and signatures themselves.
- Field relationship map. A table "placeholder → source in CRM or accounting system → substitution rule → behavior when value is empty." It shows where each detail comes from and why it might not have been inserted in a specific card.
- Print access policies. Roles and rights: who generates the invoice, who edits the template, who approves changes. Editing a draft does not affect already sent documents, and deleting a template is unavailable to an ordinary employee.
- Employee instructions. One to two pages: how to generate an invoice, what to check before sending, where to report a discrepancy in details. Without describing internal design — only the working sequence.
- Update regulation. Procedure for changing details, bank, rates, or company structure: who initiates the edit, how it is tested on a trial invoice, and how it is rolled back.
- Generation log. Records from which template and with which data the document was assembled — in a disputed situation, it is visible exactly what went to the client.
- Set of test scenarios. Checks on clients with long names, without TIN, with several contracts — so that the template does not break on non-typical cards.
The package is handed over with a single entry point: the field map and instructions are next to each other, and the update regulation is tied to the process owner. Describe the task — we will come back with an estimate and a plan.
Case: reduced manual entry of details in documents
How it was
The sales department with four branches managed invoices manually: the manager assembled details from correspondence, a previous document, or a client card that no one updated. When the legal entity or servicing bank changed, the previous data ended up in the invoice.
Preparation took 25–40 minutes, and accounting returned 18% of documents for reissue — each return dragged out repeated approval and delayed payment.
What was changed and what the result was
Details were moved into a single directory and linked to the company card: legal entity, bank, address, and signatory are inserted into the template automatically when a deal and contract are selected.
The directory is synchronized with the accounting system through a scheduled exchange — a client's bank change arrives once and immediately to all branches. The print form template in Bitrix24 is versioned, so invoices for closed deals are not rewritten retroactively.
Before upload, the document passes a check: mandatory fields, TIN and KPP format, and the legal entity's correspondence to the contract. If a field is empty or the data does not match, the invoice is not generated — the manager sees exactly what to fill in.
Rights were separated by branch, and edits to details are written to the log with the author and time.
Invoice preparation was reduced to 3–5 minutes, and the share of documents for reissue — from 18% to 1–2%.
The manager is not distracted by reconciliation, accounting does not sort through a pile of returns at the end of the month, and in case of a discrepancy it is visible who changed the details and when.
What to do if details are already maintained in 1C?
There must be a single source of truth — the accounting system. In 1C, the counterparty is created and edited, while the client card only receives this data and stores what is not in accounting: invoice contact, delivery address, special terms.
Then the invoice template collects details from one place, and discrepancies between the print form and the directory do not arise.
The synchronization procedure is one-way: changes go out from accounting by event, not by a full upload on a schedule. The matching key is the counterparty's internal identifier, not the name: names change and are duplicated, hence two cards for one organization.
Discrepancies go into a log that is reviewed according to the regulation, not "when someone notices."
The trap is fields editable in the card. If the exchange overwrites it entirely, manual edits are erased on every pass. We move local additions into separate attributes that synchronization does not touch, and record this in the field mapping map.
Duplication of directories is treated not with a one-time cleanup but with merge rules: name normalization, matching by tax number, and a queue of ambiguous records for manual linking.
A new counterparty appears only in the accounting system — creation from the card is closed, otherwise two sources of truth will return.
Procedure: audit of invoice fields, mapping table, test run on a database copy, enabling writes, and processing the discrepancy queue. After that, the template prints what actually lies in accounting.
Technical questions asked before the start
Before the start, people ask not about invoice layout but about how the template will behave inside the system: what happens during an update, who has the right to edit the print form, and what will happen to already issued documents. Below are answers to what most often comes up in a technical review.
How do system updates affect a customized template?
The print form is stored separately from the core, so a standard update does not overwrite it. The risk is different: if an update changes the set of fields in cards, the auto-fill binding for details may diverge.
After major updates, we reconcile the fields and fix the binding — this is an edit inside the template, without rewriting the logic.
What will happen to invoices issued before implementation?
The template is applied at the moment of printing, so previously saved documents remain in their previous form. If archived invoices need to be reprinted in the new form, this is done in a separate pass and agreed in advance.
What access is needed and what remains with us after handover?
A separate user is needed with the right to configure print forms and read card fields — full administrative access is not required. After handover, the template, the description of the detail binding, and instructions for typical edits remain; the service account is disabled.
How long does implementation take and how is the template edited afterward?
Assembling the form with auto-filling takes several days, together with reconciliation on a test invoice. Text and layout edits are made in the same template, while changing the set of fields requires approval of a new binding.
Let's discuss the task and come back with an estimate and a plan
To come back with an estimate and a plan, rather than general wording, a few inputs are enough. Below is what to send so that the task review fits into one conversation. If some data is missing, this will not stop the estimate: we will discuss what to replace it with.
- an export of the invoice card or the current print form — they show which fields are already filled in;
- a sample template (Word, Excel, PDF) with notes on what is entered manually;
- a list of details and substitution rules: by counterparty, contract, deal, company;
- a description of directories and links — where to take bank data, the signatory, and the basis;
- where the invoice is generated: in the CRM, in the accounting system, or in an external service;
- access restrictions: who can access the print form and who can change the template;
- the contact of the person responsible who approves the final appearance of the document.
The review proceeds step by step: we look at the form and the invoice card, reconcile fields with directories, mark where data is entered manually, and separate what is closed by configuration and what requires development.
Based on the discussion, you receive a field and link map, an estimate of the scope of work, a stage-by-stage implementation plan, and the procedure for handing the template over to support — with a record of who is responsible for changes.
The discussion does not obligate you to start work: describe the task — we will come back with an estimate and a plan.