Why Bitrix24 report setup diverges from the facts
The funnel summary almost always diverges from payments, and the reason is not the report arithmetic but the data it is built on.
A typical dashboard calculates amounts by deal card fields — "amount," "stage," "closing date" — while the actual fact lives in payment documents of the accounting system.
Until these two circuits are linked by a matching rule, Bitrix24 report setup shows a plan instead of money.
A separate line of discrepancies is manual exports from CRM.
A manager filters deals by modification date, a finance specialist by payment date; the time zone of the portal and the accounting system may differ, and deals closed on the last day of the month fall into different periods.
Add inventory: item nomenclature in a deal is entered as text, directories in CRM and accounting do not match — and the sales summary stops reconciling with shipments.
The third cause is duplicate deals. Emails and forms create repeat inquiries, automation does not always merge them, and two amounts for one deal enter the report.
Data quality in CRM directly affects the figure: an unfilled stage, an empty amount, or a deal without an owner breaks both grouping and the total.
Until sources, matching rules, and directories are sorted out, the report remains decorative. Below is how this is closed.
Effect of managed analytics: what changes in work
The effect of managed analytics is visible in three metrics. Management summary stops being a separate task: automatic CRM reports are assembled on a schedule — by stages, owners, sources, and periods.
Preparation goes from hours of manual reconciliation to several minutes, and values in the summary match the cards because they are calculated from them rather than transferred by hand.
A unified sales funnel closes a whole class of double-counting errors: a deal created from an email and duplicated by a manager is merged by requisites and does not enter the report twice.
The share of discrepancies between the summary and primary data falls to the level of manual input error — there is nothing left to argue about at a planning meeting over whose figure is correct.
Reducing manual exports also removes the gap between the report and the card: both are calculated from one source, and intermediate tables no longer live their own life.
A stage deviation is visible the same day — thresholds highlight stuck deals, and reaction happens based on fact, not at the end of the month from memory.
Bitrix24 provides data through standard entities — deals, tasks, calls, invoices; where accounting logic is custom, we calculate aggregates as a separate layer on top.
Calculation rules, update regulations, and access rights are specified by role so the report cannot be adjusted by hand bypassing history.
Comparison of analytics approaches: table of modes
The choice of approach is determined not by data volume but by the questions that arise for analytics. Built-in analytics covers the operational picture: funnel, manager activity, amounts for the period.
As soon as you need a slice across several areas, period comparison with overlay, or a sample deeper than a year, the limitations of built-in analytics get in the way — calculation runs on the same CRM entities, and history is lost when statuses change and fields are recreated.
| Option | When suitable | Limitations |
|---|---|---|
| Built-in panels | Operational funnel control, slices for the current month | No arbitrary slices, heavy periods calculate slowly, history depth limited by entity settings |
| External data mart | Summaries across all areas, period comparison, history over years | Requires export to storage and an update schedule, some fields are normalized at input |
| Hybrid scheme | Operational questions — in CRM, management analytics — on a separate platform | Two circuits of rights and two calculation logics, constant discrepancy control needed |
| Manual reconciliations per regulations | One-off slices, period closing, checking suspicious figures | Manual labor, no repeatability or accumulated history |
The choice is rarely "either one or the other." Usually an external data mart covers regular management reporting, panels remain for operational tasks, and manual reconciliations work as control.
At the start, we assemble one or two key slices and reconcile them with CRM data down to the digit — a discrepancy immediately shows which calculation rules are missing.
How implementation proceeds: stages of engineering work
A sales report breaks not on the chart but at the input: fields are filled inconsistently, some deals are entered manually, stages are duplicated for different departments.
That is why implementation starts with data, not widgets — otherwise the dashboard draws beautiful and incorrect numbers.
-
Data source audit. We analyze which channels create leads, where inquiries are lost, and which fields are filled formally. We record duplicates and deals without an owner — these are exactly what later distort the funnel.
-
CRM data map. We match entities: lead, deal, contact, company, invoice, call, task. We agree on which stages count as a sale, which date measures the period, and what is required to enter the report.
-
Data model schema. Some indicators we calculate on the fly, some — in calculation tables with owner directories and periodic rebuilding. The report opens in seconds on tens of thousands of deals instead of recalculating the entire database.
-
Setup of reports and dashboards. We assemble slices by areas, funnels, and managers, configure saved filters and access rights: a department head sees their block, a commercial director sees the summary.
-
Reconciliation check on real deals. We take closed deals for the previous period and compare report figures with manual counting by cards. We investigate discrepancies to the cause: wrong date, missed stage, duplicated deal.
-
Handover and training. We provide regulations: how to add a stage or field so the report does not fall apart, and who is responsible for fill quality. We show managers ready-made slices and scenarios for reading them.
Project handover: documentation, schemas, and regulations
Project handover is not granting access to the admin panel but a set by which a new administrator reproduces reporting without us. We assemble it so that each artifact closes its own class of questions that otherwise surface a month after launch.
- Configured panels and sections: dashboards by funnel and sources with a description of which question each answers.
- Data model schema: directories, fields, and relationships in the calculation; marked what comes from 1C and what is filled manually.
- Documentation on metrics: formulas for conversion, deal cycle, and revenue — with filters, periods, and boundary conditions.
- Data access policies: roles by departments and regions, what a head and a manager see, where personal data is masked.
- Report update regulations: frequency of synchronization with 1C, actions on failure, who is responsible for recalculating history.
- Reconciliation regulations: control totals on a schedule and an escalation rule for discrepancies above the threshold.
- Instructions for managers: required fields, stage management, what to do if a deal did not enter the report.
- Change log: what, when, and why changed in reports — the basis for rollbacks and incident analysis.
We keep the set in one repository with settings and version it together with them. Then on the next reporting change it is clear what was before, who changed it, and why — and handover does not turn into verbal agreements.
Case: how CRM reports matched reality in a month
The client is a sales department with several areas.
Deals were kept in CRM, but the summary for management was assembled manually: an analyst exported data into tables, reconciled them with the accounting system, and delivered the report in two or three days, when some figures had already become outdated.
Disputed deals were discussed at stand-ups, and discrepancies were written off to "human factor."
At the stage of analytics implementation, we bet on input data quality rather than the visual appeal of charts.
We closed required fields at every funnel stage, configured auto-filling of the owner and inquiry source, linked deals to accounting system documents by number, and prohibited closing a deal without a specified result. After report setup, the summary is assembled on a schedule without an analyst's involvement.
| Metric | Before | After |
|---|---|---|
| Summary preparation time | 2–3 days | 15 minutes, on schedule |
| Discrepancies with accounting system | 17% of rows | Less than 1% |
| Disputed deals per month | 30 or more | 4 |
| Deals with key fields filled | 58% | 97% |
Why these figures began to be trusted
CRM data accuracy is confirmed by independent sources: a payment register, call log, export from Bitrix24, and primary documents.
A discrepancy is visible at the level of an individual record, not at the level of the final total, so the cause is found in minutes, not in a day of reconciliations.
What to do if CRM data is already filled with errors?
There is no need to wait until the database becomes ideal: reports are built on top of current data, but with explicit caveats. First, in Bitrix24, we define the fields involved in calculations — amount, stage, source, owner, closing date.
Periods where these fields were filled chaotically are marked as unreliable and excluded from comparisons so the dynamics do not show false growth.
In parallel, we enable rules for required deal fields. A deal does not move to the next stage until key attributes are filled, and we close directories from free input: the value is selected from a list rather than typed by hand. This stops the emergence of new discrepancies — cleanup stops being endless.
Normalization of directories proceeds over accumulated history: we find duplicates and variant spellings of the same value, match them, and reduce them to a single form. Separately, we process cards without a link to a client or owner — they distort any summary.
Step-by-step CRM data cleanup proceeds by impact on reporting: first fields from calculations, then analytical slices, and only then the archive. We record each stage with a before-and-after slice, so it is clear which discrepancies are closed and which remain. Analytics becomes suitable for decisions without waiting for a full database rebuild.
Common technical doubts about CRM analytics
Before launching a panel, managers ask the same questions: how much can figures be trusted, how to combine several sources into one picture, and will reporting start slowing down the department. Below are direct answers from our engineers on Bitrix24, without the phrase "it depends."
Some of these doubts are resolved not by interface settings but by the data model and access rights. That is why the answers begin with where the boundary lies between the source, the report storage, and the panel.
How accurate are reports if managers fill in cards carelessly?
The report reads card fields: if a deal stage is not moved, the funnel will show a distorted result.
We make key fields required at stages where they affect figures and display the share of unfilled cards in the panel — it is visible which department is lagging and where the process, not the report, needs correction.
How are data sources combined?
Deals, calls, emails, messages from messengers, website requests, and accounting documents are brought into one layer via the "contact — deal" link.
Duplicates are collapsed according to merge rules, and discrepancies between sources are not hidden but displayed as a separate line — otherwise the total looks smooth but incorrect.
How often are panels updated, and does this create load on CRM?
Heavy slices are calculated on a schedule, light ones noticeably more often, but recalculation runs in a separate stream and does not block managers' work.
We rebuild only changed data rather than the entire array: as the database grows, report build time grows more slowly than deal volume.
What will happen to reports after a system update?
Panels are built on standard objects and exports, not direct queries to service tables, so an update does not break the logic. Before a major update, we run a check on a copy and compare control figures: if a slice diverges, we fix the calculation before migration, not after.
How is access delimited by department?
Rights inherit the structure of departments and roles: a head sees the funnel of their unit, a manager — only their own deals. Restrictions are set at the level of the report and fields, not only the interface, so exporting to a file returns the same permitted slice.
Let's discuss the task: what is needed to start
To come back with an estimate and work plan rather than general words, we need a minimum of inputs. Usually one review is enough: after it, it is clear how many reports to configure and what data for them already exists.
- Statement of the reporting task: questions that analytics should answer — funnel by stages, sources, conversion between stages, manager workload.
- Access for audit: Bitrix24 portal with rights to view settings — funnels, custom fields, roles. Without this, the estimate will be approximate.
- CRM structure: which areas and funnels are in use, which fields are required, whether there are smart processes.
- Data sources: telephony, email, website forms, messengers, 1C — what is already connected and what needs to be linked to reports.
- Access restrictions: who sees which figures — area head, branch, individual manager. The logic of filters and roles depends on this.
- What is unsatisfactory now: examples of current reports and dashboards, which metrics are calculated incorrectly or collected manually.
- Work mode: when settings can be changed on the live portal and whether there are periods when edits are unacceptable.
Then we return with a plan: composition of reports and dashboards, metric calculation scheme, stages, and what is needed from you at each. Describe the analytics task — we will return with an estimate and work plan.