User Story

As a Billing Administrator of a Communication Service Provider (CSP), I need a complete toolkit to correct xDR data at any stage of its lifecycle: from precise re-rating of xDRs for accounts provisioned with a temporary tariff, to rollback of erroneously imported collections, and re-processing of mismatched billing parameters — so that customers are always charged correctly regardless of when errors are discovered, and so that accurate xDR data is delivered to customers automatically by email without manual intervention.

As a CSP (who on-boards wholesale customers using temporary dummy tariffs while final commercial agreements are negotiated, and who receives large CDR file batches from carriers that may contain errors), I would like to:

1. Start providing service to a new customer immediately by assigning a temporary tariff, and later switch each account to its own correct tariff and re-rate all historical XDRs for that account only — without affecting other accounts that share the same dummy tariff — so that provisioning and billing can work in parallel without blocking each other.
2. Re-rate XDRs not just at the customer level, but also filtered by individual account and by destination code group or individual prefix — to make surgical corrections when only specific routes were mispriced, without touching correctly rated traffic.
3. Apply re-rating and re-processing corrections to XDRs in a closed billing period, updating them in place rather than generating adjustments in the current period — so that the historical record stays accurate and customers receive a corrected CDR report for the affected period.
4. Roll back an entire erroneously imported XDR collection (or selected XDRs within it) directly from the Admin UI, with automatic customer balance recalculation — so that duplicate or incorrect file imports can be corrected quickly without Professional Services involvement (the refeed script).
5. Re-process a collection including already-successfully-rated XDRs when a billing parameter (such as MinimumCallDuration) was misconfigured at the time of import — because re-rating only changes tariff rates and cannot correct such parameters.
6. Deliver CDR reports to customers by email on a daily or weekly schedule, grouped by account or by customer, independently of the billing period — so that customers receive timely data for their own reconciliation without having to set artificial daily billing periods.

Example of use

Example 1 – Temporary tariff on new account: On March 1, 2026, the provisioning team activates account "CUST_B_Account1" for customer "Customer B". The final tariff is not yet ready, so the account is assigned a generic dummy product "DUMMY_PRODUCT". On March 18, the finance team finalises the tariff "CUST_B_REAL_PRODUCT". The Billing Administrator assigns the correct tariff to account "CUST_B_Account1" and runs re-rating filtered by account, replacing all XDRs from March 1–18. The other account "CUST_B_Account2", which also uses DUMMY_PRODUCT, is unaffected, as his final tariff will differ. 

Example 2 – Erroneous file imported by mistake: On February 2, 2026, a source system error causes two duplicate wholesale CDR files (F2026-02-01.csv and F2026-02-02.csv, ~828 MB each, ~8 million records each) to be re-delivered to the SFTP and processed by XDR Mediator, creating collections f2026_02_01_edr_20260202_1103 and f2026_02_02_edr_20260203_1106 with duplicate charges. CSP requests deletion of these two collections and recalculation of customer balances. Currently, this requires a Professional Services (the refeed script). The requested feature allows the Billing Administrator to roll back a collection from the Admin UI.

Example 3 – MinimumCallDuration misconfiguration: Customer "CUST_C_Account" was billed with MinimumCallDuration=60 instead of the agreed value of 6 seconds. This parameter cannot be corrected by re-rating (re-rating only changes tariff rates). The entire collection must be re-processed with corrected billing parameters. CSP needs to re-process 138 XDRs for that account from collection 20250901_0502_279645800792062_0792, including already-successful XDRs, replacing their charged amounts.

Example 4 – Automatic daily CDR email: Customer "Customer A" requires a daily CDR file grouped by account, delivered to customer-billing@example.com each morning. Currently, PortaBilling can only send a CDR report when a billing period closes, forcing CSP to set the billing period to "daily" — which breaks re-rating (re-rated XDRs land in the current open period rather than the past closed one). The requested feature decouples CDR report delivery frequency from the billing period.

Business model

Wholesale VoIP and Messaging service. Traffic is processed at working hours in America TZ. Amount of XDRs on weekend and at nights is close to zero. 

CSP operates a wholesale VoIP and messaging platform migrated from Jerasoft. Their operational model has two departments:

(1) Provisioning creates accounts immediately, assigning generic "dummy" tariffs (Voice Calls COL, MX, Peru, USD) because final commercial agreements take days to weeks to conclude; 

(2) Finance assigns correct tariffs later and re-rates historical traffic. Because multiple accounts share the same initial dummy tariff, the current PortaBilling re-rating scope (Customer + wrong tariff) cannot isolate one account's XDRs, causing unintended recalculation of other accounts.

Technology

Systems involved:

• PortaBilling (MR122-0) – billing engine, re-rating wizard, XDR History Report, customer balance management
• XDR Mediator – imports CDR files every 5 min from SFTP/filesystem into Collections; creates XDR records in OpenSearch and MySQL. 
• OpenSearch – stores XDR data; queried for re-rating, reports, and collection re-processing
• Customer Self-Care UI (CSC) – customer-facing Reports page (Archived XDRs)
• Email delivery subsystem (SMTP) – sends XDR History Report CSV files on schedule or on demand

Current Solution

New Tariff limitation : When the correct tariff is created after traffic has already been terminated, all rates in that tariff have effective_from >= today. Re-rating looks for a rate effective at the time of each call, so it will not find the new rate for historical XDRs. The Billing Administrator must back-date the rates (set effective_from to the start of the service) before running re-rating or re-processing. Currently, this requires either a direct database UPDATE or running the update_effective_from.pl script on the server. The goal is to provide this capability through the Admin UI.

Re-rating scope limitation : The Re-rating wizard filters XDRs by Customer + wrong tariff. It has no filter by i_account or rate code/code group. When multiple accounts of the same customer share an initial dummy tariff, re-rating one account re-rates all of them simultaneously. Workaround: create a unique initial dummy tariff per account — operationally unsustainable at scale.

Re-rating in closed billing period :

• Re-rating does not update XDRs in a closed billing period. XDRs re-rated after period close are generated in the current open period, leaving the closed-period report incorrect. There is no built-in mechanism to regenerate or re-send the XDR History Report after re-rating. 
• Invoices are issued in an external system, where line items are imported from the Summary Report via Datalink. Therefore, correcting XDRs after invoice issuance does not require voiding the PortaBilling invoice — a credit note in the external system is sufficient. The Summary report for the closed period must include the updated XDRs.

Collection rollback : When CDR files are imported by mistake, there is no UI to delete or roll back a collection. The only solution is the PortaOne Professional Services "refeed" script, which requires manual engagement, 4–8h turnaround, and direct database access. For ~8 million record collections this is a significant operational risk.

Collection re-processing of successful XDRs : Collection re-processing in the current UI can only re-process XDRs that failed matching (error XDRs). Successfully rated XDRs cannot be re-processed even if the billing parameter (e.g. MinimumCallDuration) was configured incorrectly. Workaround: manually update XDRs in MySQL/OpenSearch — an unsupported and risky procedure.

Automatic XDR email delivery : CDR reports are only sent automatically at billing period close. To receive daily CDRs, CSP must set the billing period to "daily" — which conflicts with re-rating (closed daily periods cannot be re-rated in the current system). There is no decoupled CDR delivery schedule independent of the billing period (mostly monthly and weekly).

Stakeholders and their benefits

Who are the users / whom we bring value to?

• Billing Administrator (CSP) – surgical re-rating per account/rate code; collection rollback in UI; saves ~3–8h per correction incident
• Provisioning Team (CSP) – can activate accounts immediately with generic initial dummy tariff, without blocking on finance team; no need to create unique initial dummy tariffs per account, no need to request Proffesional Service to set effective_from to the past date.
• Finance Team (CSP) – correct tariff applied retroactively per account without affecting other accounts; confidence that CDR files reflect agreed rates
• End Customers of CSP – receive daily/weekly CDR email automatically; always receive up-to-date XDR History Report after re-rating
• PortaOne Professional Services – no longer engaged for emergency XDR refeed scripts
• PortaOne Product – closes gap with Jerasoft on account and/or rate code level re-rating granularity 

Use Cases

Use Case #1: Allow Service for Customer Now, Assign Proper Tariff Later

The provisioning team activates a new account with a generic initial dummy tariff. When the correct tariff is ready (days or weeks later), the Billing Administrator assigns it and re-rates historical XDRs for that account only, without affecting other accounts sharing the same initial dummy tariff.

Use scenario #1.1: Creating rates with effective_from in the past so that re-rating and re-processing covers historical XDRs

At 2026-03-20 08:00:00, Finance team is ready to create tariff CUST_A_ACC1_REAL_TARIFF for account CUST_A_Account1.

Traffic for this account started on 2026-03-01, so rates must be effective from that date.

Billing Administrator opens the new tariff in Admin UI and begins preparing tariffs: 

• • opens the tariff in Admin UI and enters new rates with effective_from: 2026-03-01 00:00:00;
  • saves the tariff. System stores all rates with effective_from = 2026-03-01 00:00:00;
  • creates tariff CUST_A_ACC2_REAL_TARIFF in similar manner;
  • assigns CUST_A_ACC1_REAL_TARIFF to CUST_A_Account1;
  • assigns CUST_A_ACC2_REAL_TARIFF to CUST_A_Account2;

Use scenario #1.2: Sequential per-account re-rating on the same initial dummy tariff, each with a different correct tariff

At 2026-03-20 09:00:00, Billing Administrator opens Re-rating wizard. 

• • Selects Customer: "Customer A";
  • Account: "CUST_A_Account1";
  • Sets Wrong Tariff: "CUST_A_DUMMY_TARIFF";
  • Correct Tariff: "CUST_A_ACC1_REAL_TARIFF";
  • time range 2026-03-01 – 2026-03-20.

Administrator confirms. Job RERATE-20260320-XXXXX9 runs.

At 2026-03-20 09:11:14, job completes. 3,100 XDRs for account CUST_A_Account1 updated with CUST_A_ACC1_REAL_TARIFF rates. 

XDRs of the the account "CUST_A_Account2" remain unchanged.

Administrator immediately opens a second re-rating job. Selects same Customer, Account: "CUST_A_Account2".

• • Sets Wrong Tariff: "CUST_A_DUMMY_TARIFF";
  • Correct Tariff: "CUST_A_ACC2_REAL_TARIFF";
  • same time range.

Administrator confirms. Job RERATE-20260320-XXXXX1 runs.

At 2026-03-20 09:29:45, job completes. 4,872 XDRs for account CUST_A_Account2 updated with CUST_A_ACC2_REAL_TARIFF rates.

Use Case #2: Re-rating by rate code group and Individual Code

The finance team needs to correct rates for a specific rate code group (e.g., MEXICO MOB) or individual rate code (e.g., 5215) without re-rating all rate codes for that account.

Use scenario #2.1: Re-rating filtered by rate code group

At 2026-04-10 14:05:00, Billing Administrator opens Re-rating wizard. Selects 

• • Customer: Customer A, Account: CUST_A_Account2.
  • Expands Rate Code Filter section. Selects rate code group: "MEXICO MOB". 
  • Time range: 2026-04-01 – 2026-04-09.
  • Sets Wrong Tariff: "CUST_A_ACC2_REAL_TARIFF" (old rates);   nice-to-have alternative: currently active tariff
  • Correct Tariff: "CUST_A_ACC2_REAL_TARIFF" (same tariff, rates corrected in-place); nice-to-have alternative:  currently active tariff

Administrator confirms. Job RERATE-20260410-XXXXX runs.

At 2026-04-10 14:11:22, job completes. 1,247 XDRs updated out of 15M.

The other XDRs remain untouched disregarding whether their rates have been updated or not.

Overall processing time reduced due to only 1247 XDRs have been processed out of 15M.  

Use scenario #2.2: Re-rating filtered by individual rate code

Billing Administrator opens Re-rating wizard. Selects 

• • Customer: Customer A.
  • Account: CUST_A_Account1.
  • Expands Rate Code Filter section. Selects Individual Rate Code "5215".
  • Time range: 2026-04-01 – 2026-04-09.
  • Sets Wrong Tariff: "CUST_A_ACC1_REAL_TARIFF" (old rates);   nice-to-have alternative:  currently active tariff
  • Correct Tariff: "CUST_A_ACC1_REAL_TARIFF" (same tariff, rates corrected in-place); nice-to-have alternative:  currently active tariff

Administrator confirms. Job RERATE-20260410-XXXXX runs and completes. 89 XDRs updated out of 800K. 

The other XDRs remain untouched disregarding whether their rates have been updated or not.

Overall processing time reduced due to only 89 XDRs have been processed out of 800K.  

Use Case #3: Insert / Update XDRs in a Closed Billing Period

After a billing period closes, re-rating must update XDRs in place within the closed period (not generate them in the current open period), and must trigger regeneration History Report CSV file.

Use scenario #3.1: Re-rating updates XDRs in a closed billing period and XDR History Report regenerated and re-sent

At 2026-04-17 09:30:00, Billing Administrator opens Re-rating wizard. Selects Customer: Customer A, Account: CUST_A_Account2.

• • Sets time range: 2026-03-01 – 2026-03-31 (falls within closed period). System displays warning: "Selected range includes closed billing period (March 2026). XDRs will be updated in the closed period. XDR History Report will be regenerated and re-sent."
  • Sets Wrong Tariff: "CUST_A_DUMMY_TARIFF"; Correct Tariff: "CUST_A_ACC2_REAL_TARIFF".

Administrator confirms. Re-rating Job RERATE-20260417-XXXXX starts.

At 2026-04-17 09:47:12, re-rating completes. 4,872 XDRs updated in closed period.

System automatically triggers XDR History Report regeneration for "Customer A".  "XDR_History_CustA_202603_revised_20260417.csv" and uploads to Reports archive, replacing the March file. nice-to-have alternative: same file name

At 2026-04-17 09:49:55, Billing Administrator receives confirmation in Admin UI: "Re-rating complete. XDR History Report regeneration scheduled."

Financial team re-generates Summary report in Datalink. Exports the report to external invoicing system. Invoice totals for "INV-2026-03-Customer A" updated or a credit note "CNV-2026-03-Customer A-CN1" for COP 427.83 is issued (if the invoice has been paid already).

Use Case #4: Re-processing Imported XDRs (Rollback and Re-calculation)

An XDR file was uploaded and processed by XDR Mediator by mistake (source error, duplicate delivery). The Billing Administrator needs to roll back the entire collection: delete all XDRs from that collection and recalculate customer balances, without Professional Services involvement.

Use scenario #4.1: Rollback an erroneously imported collection via Admin UI

At 2026-04-17 10:00:00, Billing Administrator navigates to XDR Mediation → Collections.

Locates collection "f2026_04_01_edr_20260402_1103". Details: 8,021,440 XDRs, file F2026-04-01.csv, imported 2026-04-02 02:07:00. nice-to-have: Status: ACTIVE.

Administrator clicks "Roll Back Collection". System displays warning: "This will delete 8,021,440 XDRs, recalculate balances for 47 affected customers, and mark the collection as ROLLED_BACK. This action cannot be undone. Confirm?"

Administrator clicks "Confirm Rollback". Job ROLLBACK-20260417-XXXXX starts.

System deletes 8,021,440 XDRs from OpenSearch and MySQL for this collection. Recalculates balances for all 47 affected customers. nice-to-have: Collection status → ROLLED BACK.

At 2026-04-17 11:42:17, job completes. Admin UI shows: "Rollback complete. 8,021,440 XDRs deleted. 47 customer balances recalculated."

Administrator repeats these steps for collection "f2026_02_02_edr_20260203_1106".

NOC and/or Financial team generate Summary report and compare "Total transactions" against the GW (the one that generates CSV files with source XDRs). Total amount of transactions is correct now.

Use scenario #4.2: Rollback successfull XDRs by criteria across multiple collections in open and closed billing period

If only specific successfull XDRs need to be deleted (e.g., for a particular account and/or time window), the Administrator can filter by criteria before initiating rollback.

Administrator opens xDRs search across multiple collections. Selects:

• • service: voice calls
  • customer: CUST_C
  • username: CUST_C_Account1
  • vendor: VENDOR_ABC
  • CLD: 52 (pattern: contain, or start with, or end with)
  • time window: 2026-03-01 10:15:00 - 2026-04-18 00:00:00

Administrator clicks "Delete selected XDRs".

System deletes 138 XDRs (110 in closed and 28 in open billing period) across 1317 collections (all collections withing the time window) matching the criteria and recalculates affected balances (i.e. CUST_C_Account1, CUST_C, VENDOR_ABC).

Billing Administrator receives confirmation in Admin UI: "Re-processing complete. XDR History Report regeneration scheduled." nice-to-have: The affected collections statuses → PARTIALLY ROLLBACK. 

Use scenario #4.3: Re-process XDRs by criteria across multiple collections in open and closed billing period

 Administrator would like to find both successfull and unsuccessfull XDRs matching the criteria, fix the root cause and re-process.

 The criteria is matched against collection properties in OpenSearch, as the XDR may be unsuccessfull (charging error) as well as succesffull.
 Administrator opens xDRs search across multiple collections. Selects:

• • service type: voice 

System populates additional criterias for this type of service: 

The set of filter criterias may differ based on service type (voice, messaging etc.). The search criteria should allow searching by the attributes specific to the selected service type. 

We assume the fllowing attributes are mandatory for each service type, see the link
https://docs.portaone.com/handbook/MR90/xDR_Import/xDR_Import_Configuration/xDR_Import_Configuration.htm?rhhlterm=Mediation&rhsyns=%20#Mandatory_attributes_for

• • username: CUST_C_Account1 (pattern: contain, or start with, or end with)
  • CLD: 52 (pattern: contain, or start with, or end with)
  • CLI: any 
  • vendor
  • duration
  • time window: 2026-03-01 10:15:00 - 2026-04-18 00:00:00
  • error type: customer charge error  (or vendor charge error|parsing error)
•  
• System populates additional criterias for this type of error: 

The set of filter criterias may differ based on the error type. The search criteria should allow searching by the attributes specific to the selected service type. 

At least, it has to provide: 

• • • vendor charge error: unable to match vendor,
    • vendor charge error: unmatched destination,
    • customer charge error: unable to match account, 
    • customer charge error: unmatched destination

• • error reason: unmatched destination (or any other available for the selected error type).  

Administrator clicks "Re-process selected XDRs".

System re-processes 4200 XDRs (1000 successfull and 3200 unsuccessfull in both closed open billing periods) across 1317 collections (all collections withing the time window) matching the criteria and recalculates affected balances (i.e. CUST_C_Account1, CUST_C, VENDOR_ABC).

Billing Administrator receives confirmation in Admin UI: "Re-processing complete. XDR History Report regeneration scheduled." nice-to-have: The affected collections statuses → PARTIALLY RE-PROCESSED. 

Use Case #5: Automatic Daily / Weekly CDR Email Delivery to Customers

Customers require CDR files delivered to their email on a daily or weekly schedule independent of the billing period. This must work even when the billing period is monthly or weekly — decoupled from period close events.

Use scenario #5.1: Re-rated/Re-processed XDRs cause revised daily XDR History Report report to be re-generated

On 2026-04-10, Billing Administrator re-rates 1,247 XDRs for account 4121, period 2026-04-01 (as in Use Case #3). The daily XDR report for 2026-04-01 was already generated on 2026-04-02.

Upon re-rating completion, system detects that XDRs from 2026-04-01 were already included in the generated daily XDR report.

System regenerates the XDR report for 2026-04-01

nice-to-have alternative:  The log updated with the re-rating job ID or notification is sent to Billing Admininstrator.

The Billing Administrator verifies that a new file has been generated, downloads it, and forwards it to the customer if necessary.

  

Wireframes

Identifying discrepancies between individual XDRs and the Summary report (e.g., an account showing billed volume = 0 despite a total volume of 4.35).

Recalculating XDRs for a specific destination after correcting the associated rate.

Non-functional requirements

Availability:

• Re-rating, re-processing, and rollback jobs must be resumable after system restart. XDRs not yet processed must retain their original values.
• Collection rollback jobs are serialized (one at a time per collection).

Data Integrity:

• Re-rating must be idempotent: running the same job twice on the same XDRs produces the same result.
• Daily CDR delivery must not create or close billing periods.

nice-to-have alternative:

Audit and Traceability:

• Every re-rated XDR must record: re-rating timestamp, job ID, previous charged_amount, new charged_amount, admin i_env.
• Every rolled-back collection must record: rollback timestamp, job ID, admin i_env, XDR count deleted.

Peculiarities

Historical Depth (Re-rating & Re-processing): Updating, deleting, or inserting XDRs must be supported for the last 2 months (the current open period and the one previous closed monthly billing period).

Performance / Clustering, Geo Redundancy/ Dual-Version, Porter / Call Control API / ESPF / Monitoring

The system is processing 1.5-2.5 bln XDRs per month, at peak up to 2500 XDR/sec. 

Timing for the aforementioned operations must be reasonable.