Treat call logging and call reconciliation as separate responsibilities. Logging delivers activities to the CRM; reconciliation checks whether the expected activities exist, contain the right technical facts and remain explainable after retries or repairs. For telecom founders, product leaders and operations teams, the useful deliverable is not simply matching daily totals. It is a repeatable process that identifies missing, duplicate and inconsistent records, separates genuine defects from legitimate differences, and repairs only what the integration owns.
1. Define what one reconciled call means
Start with a written contract: which calls belong in the CRM, which source establishes technical facts, and whether one activity represents a customer interaction, an agent segment or an individual call leg. Explicitly classify internal calls, abandoned queue calls, voicemail, transfers and failed outbound attempts. Do not compare raw PBX row counts with CRM activity counts until both datasets have been reduced to that agreed unit.
Asterisk illustrates why this matters. Its CDR specification applies to Asterisk 12 and later and describes separate records for communication paths, with linkedid associating related records. Transfers can therefore produce several CDRs. The specification also warns that some SIP-protocol attended transfers cannot be correlated using linkedid, uniqueid and sequence alone. Treat grouping as a tested, platform-specific rule—not a universal identifier trick. ([docs.asterisk.org](https://docs.asterisk.org/Configuration/Reporting/Call-Detail-Records-CDR/CDR-Specification/?utm_source=openai))
Write acceptance examples before implementation. A customer who reaches an IVR, speaks to an agent and is transferred might require one customer-facing activity plus retained segment evidence. Two independently dialed attempts should remain separate. For each scenario, document expected activity count, owner, outcome and duration definition. This makes discrepancies reviewable against a contract rather than someone's recollection of the CRM screen.
2. Establish a version-aware reconciliation ledger
Create an integration-side ledger rather than relying on CRM search as your only memory. Recommended fields include tenant_id, PBX instance, source record ID, interaction ID, segment ID, CRM activity ID, event time, ingestion time, source schema version, mapping version and processing state. Preserve raw evidence under an explicit retention policy. Scope identifiers to the originating tenant and system, even when a vendor describes them as unique.
Inventory the exact extraction mechanism, build and license. For example, 3CX documents a CDR service with file and TCP output, while V20 Update 6 introduced its redesigned reporting CDR structure. These are distinct interfaces that should not be assumed interchangeable. Separately, its MySQL Data Connector guide targets V20 Update 7 and specifies a 16SC+ license prerequisite. Confirm the deployed system's entitlements and schema before choosing an extraction design. ([3cx.com](https://www.3cx.com/docs/manual/advanced-features/?utm_source=openai))
Normalize timestamps to UTC while retaining the original offset or configured source timezone. Distinguish event occurrence from arrival time, and preserve unknown values rather than turning them into zero. Store a canonical payload hash for change detection and an explicit exclusion reason for out-of-scope calls. After upgrades, validate representative exports against stored fixtures before advancing the adapter's schema version.
Let's map the integration before complexity grows.
Tell us which platforms need to connect. We'll help turn the workflow into a clear, reliable implementation plan.
Talk to iMingos ↗3. Compare semantics, not just field names
Define each comparison independently: start time, connection time, end time, elapsed duration, connected duration, technical status and business outcome. Asterisk distinguishes duration, measured from start to end, from billsec, measured from answer to end; it also notes that hold-related media restrictions are not reflected in CDRs. Consequently, neither field should automatically be labeled agent talk time. ([docs.asterisk.org](https://docs.asterisk.org/Configuration/Reporting/Call-Detail-Records-CDR/CDR-Specification/?utm_source=openai))
Check units at the adapter boundary. HubSpot's documented v3 Calls API uses milliseconds for hs_call_duration, while Asterisk CDR durations use seconds. For an illustrative 90-second value, the corresponding HubSpot value is 90000 only if both fields represent the same agreed duration. Avoid summing overlapping legs; for customer-connected elapsed time, define which intervals qualify and calculate their union rather than their arithmetic total. ([developers.hubspot.com](https://developers.hubspot.com/docs/api/crm/calls))
Keep transport status separate from sales or service outcomes. In Twilio Programmable Voice, the completed callback event can carry busy, canceled, failed or no-answer terminal statuses; CallStatus=completed can also represent an IVR or voicemail connection. Do not translate either into a successful human conversation without additional evidence. Set comparison tolerances from documented precision and measured clock behavior, and record which rule justified an accepted difference. ([twilio.com](https://www.twilio.com/docs/voice/api/call-resource))
4. Run overlapping scans and classify exceptions
Use live events for responsiveness and scheduled source scans for verification. Maintain separate ingestion and reconciliation checkpoints. Scan half-open event-time windows, such as [start, end), with an overlap sized from observed delivery delays. Treat recently ended interactions as provisional until an agreed settlement period passes. Advance the reconciliation checkpoint only after every page in the window has been processed and its exceptions durably recorded.
Do not let arrival order determine final state. Twilio documents that call-progress callbacks have SequenceNumber values but can arrive out of order. HubSpot warns that new or updated objects may take a few moments to appear in search; its current Search documentation also limits pages to 200 objects and individual queries to 10,000 results. Partition large scans into smaller windows and verify known CRM IDs directly where appropriate. ([twilio.com](https://www.twilio.com/docs/voice/api/call-resource))
Classify exceptions as missing activity, duplicate activity, field mismatch, missing association, orphan CRM activity or unresolved grouping. Calculate coverage using expected eligible interactions—not raw source rows—and report unresolved items by age, tenant, adapter and reason. A CRM-only activity may be a legitimate manual entry: do not delete it automatically. Require a read-only exception report before enabling repairs, so operators can inspect false positives.
5. Repair narrowly and prove replay safety
For each eligible interaction, enforce a unique ledger key and serialize competing writers. Persist the returned CRM activity ID. If a create request times out, mark the result uncertain and investigate before creating again; a local uniqueness constraint cannot undo a successful remote write whose response was lost. Where a supported external correlation property exists, verify its availability and search behavior rather than assuming every CRM object supports idempotent upsert.
Define field ownership before allowing updates. The PBX adapter might own technical timestamps and durations, while agents retain notes and business outcomes. HubSpot's documented v3 API supports updating a call with PATCH /crm/v3/objects/calls/{callId}, and provides separate association operations. Use narrow updates, log before-and-after values, and require review for ambiguous duplicates or destructive changes. A successful repair should also survive a subsequent verification read. ([developers.hubspot.com](https://developers.hubspot.com/docs/api/crm/calls))
Test duplicate delivery, reversed events, interrupted pagination, ambiguous timeouts, transferred calls, daylight-saving boundaries and mapping-version changes. Replaying the same fixture should create no additional activities; rerunning a repair should produce no further changes. Roll out read-only, then permit low-risk repairs, retaining human review for ambiguity. For iMingos, this is a practical integration framing: agree on evidence, ownership and recovery behavior before treating call synchronization as production-ready.
Frequently asked questions
Should PBX and CRM daily call totals always match?
Only after applying identical scope and grouping rules. Compare eligible interactions with their expected CRM activities, not unfiltered source rows. Also align timezone boundaries and allow recent interactions to settle before declaring a gap.
Can webhooks replace scheduled reconciliation?
Use them for different purposes: live delivery updates the CRM quickly, while reconciliation independently verifies completeness and correctness. Prefer a recoverable historical source for scans, and document the recovery limit when the selected interface cannot replay history.
What is the safest first automated repair?
Choose a deterministic, non-destructive correction to an integration-owned field on a known CRM activity. Log the evidence and change, verify the result, and test that rerunning the same repair becomes a no-op.
How far back should reconciliation look?
Choose the horizon from observed delivery delays, outage recovery requirements and available source retention. Combine frequent recent-window scans with less frequent historical checks. Keep uncertain writes and unresolved exceptions open independently of the normal scan horizon.