VoIP: numbers, plans, CDRs, and billing
Configure VoIP from rates to customer services and control traffic, charges, and invoicing.
Last updated: 2026-08-20
Module structure and setup order
VoIP connects DIDs, destination rate tables, commercial profiles, and call detail records. A customer service binds its profile and numbers; billing prices the assigned CDRs.
- Prepare CRM mappings and the CDR provider.
- Create a rate table and its destination prices.
- Create a profile with included-minute rules.
- Load DIDs.
- Assign the profile and DIDs to the customer service.
CRM identity mapping
The identity-data settings map CRM custom fields to gender, birth date, place of birth, province, and tax code. Select the field that actually contains each value; a label with a similar name is not enough if its stored format differs.
Tax-code mapping can inherit the choice used by billing settings. Automatic completion can decode eligible Italian individual tax codes and populate compatible fields. Use the overwrite option only after reviewing existing data, because it can replace manually corrected values.
Test the mapping on an individual and a company before relying on it for provider payloads, number registration, or emergency-service obligations.

CDR providers
Available CDR sources include UNO Communications, Convergenze, Alida, TWT, Kolmisoft MOR CSV, MessageNet, Retelit Irideos, one generic HTTP profile, and up to six custom FTP profiles. The custom FTP profiles are grouped at the bottom of the page under Custom FTP providers, with independent configuration, internal name, and status.
Configure and test one source at a time. Confirm environment, timezone, date format, caller and called-number format, duration unit, and whether the provider supplies a stable call identifier. Never import the same traffic through two paths: duplicates can lead to repeated accounting even when filenames differ.
Store credentials only in protected settings and define who may run a manual synchronization or inspect provider files.
Manual synchronization and FTP inspection
Run a bounded manual sync and monitor its state instead of resubmitting while active. Generic FTP profiles can list recent files and download one for name, columns, timezone, and content validation. Confirm deduplication before scheduled synchronization takes over.
Rate tables and destination prices
A rate table contains destination, prefix, per-minute price, and connection fee. More-specific prefixes must cover exceptions before broad rules. CSV import and bulk price actions require careful filtering, decimal and unit checks, and a sample review after import.

Commercial profiles and included minutes
A profile selects a rate table and one or more included-minute blocks. Each block defines minutes, included prefixes, and optional exclusions; * means every destination and the most specific match wins.
Minutes may be shared across all DIDs on the service or consumed independently per DID. Review reseller commission settings before making the profile available.

Loading and reading DIDs
Add a single number or a range using E.164 format without the leading plus sign. The interface also accepts the supported GNR range notation. Before importing, normalize the country prefix and verify that the start and end of a range belong to the intended operator allocation.
The list distinguishes Free, Assigned, Transferred, and Terminated numbers. Its summaries also reveal DIDs linked to a service, linked only to a customer, or left without an assignment. Use these discrepancies to reconcile inventory before offering a number to another customer.

DID detail and lifecycle
The DID detail brings together the customer, active and terminated service instances, provider-specific blocks, and related traffic. Check all of these areas before changing state; a number that appears commercially inactive may still exist in a PBX, provider portal, portability process, or recent CDR stream.
Release, terminate, reactivate, and delete have different consequences. Release returns an eligible number to availability, termination preserves its history, and reactivation restores the supported lifecycle state. Delete only data that can legally and operationally be removed; use termination when records and traffic relationships must remain auditable.
DID import preview
Bulk import begins with a preview that classifies normalized, valid, duplicate, and rejected rows. The preview does not change the DID inventory, so use it to correct country prefixes, invalid characters, reversed ranges, duplicate numbers, and unsupported GNR notation.
Execute the import only when sample rows and totals match the source allocation. Afterward, search the first, last, and several middle numbers, and confirm that existing assignments were not replaced or duplicated.
DIDs and Kolmisoft MOR
When Kolmisoft MOR is enabled, the DID detail can create a single number remotely, associate or create a MOR user, select one of that user’s devices, and assign the DID. The current API flow does not support GNR ranges.
Follow the remote order deliberately: confirm the number, locate the correct user before creating another one, select the intended device, perform the assignment, and then reload both systems. If a response is uncertain, inspect MOR before retrying so a successful remote operation is not duplicated.
Customer service assignment
The catalog service must use the VoIP module. Select a compatible profile and one or more available DIDs on the customer instance. Confirm provider readiness, customer status, and that numbers are not already bound elsewhere. This commercial assignment does not replace SIP or PBX provisioning.
CDR review and accounting
The calls page separates missing-customer records, customer records without a matching rate, and priced but uninvoiced calls. Fix DID ownership or the rate table before manual accounting.
Amounts can be recalculated by call date, date range, or caller for uninvoiced records only. Totals are VAT-exclusive and prefix summaries support allowance and pricing checks.

Manual CDR accounting
The command first counts CDRs in the current filters and requires confirmation before processing that exact scope. Verify customer, service, dates, caller, rates, and already invoiced rows, then inspect the resulting document.
Imports, exports, and privacy
CSV imports require consistent date, timezone, caller, destination, and duration fields. Test a small interval and check duplicates. Filtered exports remain downloadable until midnight and contain sensitive traffic information; restrict them to authorized roles.
Traffic billing
Traffic billing selects uninvoiced CDRs inside the customer service period. When previous traffic has already been invoiced, the next interval begins one second after the last included record so the same call window is not charged twice.
Included-minute consumption, per-minute prices, prefix matching, and connection fees come from the assigned commercial profile and rate table. Review the resulting quantities and amounts before issuing the document. Tenant isolation remains in force even if another ISP happens to store the same DID.
Termination and final invoice
A scheduled VoIP termination keeps the service in a final-processing state until the last relevant traffic can be collected. After synchronizing the final day’s CDRs, residual calls up to 23:59:59 may be invoiced without renewing the recurring subscription.
Confirm provider deactivation, DID lifecycle, last CDR synchronization time, uninvoiced traffic, and the effective termination date. The process does not create an empty traffic invoice when there are no chargeable calls. Keep the DID terminated rather than deleting required historical relationships.
Customer Area and operational control
Where enabled, the Customer Area exposes the customer’s own VoIP services, numbers, and permitted traffic information. Visibility must follow the authenticated customer and the services linked to that account; administrative CDR controls and provider credentials remain restricted.
After provisioning or billing changes, verify both perspectives: the administrative record must show the correct profile, DIDs, and accounting state, while the Customer Area must show only the information intended for the subscriber. Use a customer-specific session for this check rather than assuming that the back-office result proves front-end visibility.
Checklist
- Map required CRM data
- Configure and test one CDR path per source
- Create complete rate tables
- Define profiles and allowance blocks
- Load DIDs in E.164 format
- Assign profile and DIDs to the correct service
- Resolve missing customer and missing rate CDRs
- Review amounts before accounting
- Protect traffic exports
- Terminate instead of deleting required history