BRS – XDR Lifecycle Management: Re-rating, Collection Re-processing, and CDR Delivery

User Story

As a CSP (who on-boards wholesale customers using temporary initial 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 initial 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 rate code group or individual rate code — 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.
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 initial 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.
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 "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

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.
Additionally, CSP receives ~8 million CDRs per daily file from wholesale partners via SFTP. Source-side errors occasionally deliver duplicate files. Bulk deletion of erroneously imported XDR collections currently requires PortaOne Professional Services engagement (estimated 4–8h per incident). CSP also needs MinimumCallDuration and other billing parameters applied per-account, with the ability to re-process collections when a parameter was misconfigured.
Money flow: Re-rating corrections typically reduce charges by 5–15% per affected period. A single erroneous 8-million-record collection can overcharge customers by tens of thousands of USD per day. Automated daily CDR delivery eliminates 2–3 hours of manual work per customer per day for CSP's operations team.
KPIs: Reduce re-rating engineering time from ~3h to <15 min per event. Enable collection rollback in <30 min without Professional Services. Deliver daily/weekly CDR emails automatically to 50+ wholesale customers.

Technology

Systems involved:

• PortaBilling (PortaSwitch MR122-0) – billing engine, re-rating wizard, XDR History Report, customer balance management
• XDR Mediator – imports CDR files 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

Key data objects:

• XDR – fields: i_xdr, i_account, i_customer, connect_time, duration, charged_quantity, charged_amount, i_tariff, destination, i_collection, billing_params (incl. MinimumCallDuration)
• Collection – a batch of XDRs imported from a single CDR file; fields: i_collection, file_name, import_timestamp, status (active/rolled_back), xdr_count
• Billing Period (i_invoice) – fields: bill_status ('O'=open, 'C'=closed), period_from, period_to, i_customer
• CDR Delivery Schedule – per-customer configuration: frequency (daily/weekly), grouping (by account / by customer), destination email, format template
• Re-rating Job – async task: filter by i_account + rate code group/prefix + time range + wrong/correct tariff; updates charged_amount per XDR
• Re-processing Job – async task: re-applies billing parameters (MinimumCallDuration, etc.) to selected XDRs in a collection, including already-successful ones; rewrites charged_quantity and charged_amount

Current Solution

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.
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 CDR 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.

Stakeholders and Their Benefits

• 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
• 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 collection rollback scripts
• PortaOne Product – closes gap with Jerasoft on account-level re-rating granularity and collection management

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: Re-rating a single account without affecting other accounts on the same initial dummy tariff

1. At 2026-03-18 14:00:00, Billing Administrator logs into PortaBilling Admin UI.

• Opens Billing → Re-rating wizard. Selects Customer: "Customer B".
• In the new Account filter field, selects account: "CUST_B_Account1".
• Sets Wrong Tariff: "DUMMY_TARIFF"; Correct Tariff: "CUST_B_REAL_TARIFF". Time range: 2026-03-01 00:00:00 – 2026-03-17 23:59:59.

1. Administrator confirms. Re-rating Job RERATE-20260318-XXXXX starts.
2. At 2026-03-18 14:09:32, job completes. 2,340 XDRs for the account updated. Account the account XDRs unchanged.

Expected result:

• 2,340 XDRs for account CUST_B_Account1 recalculated; charged amount: USD 1,820.50 → USD 1,540.80.
• XDRs for account 5202 (CUST_B_Account2) are NOT modified — zero XDRs touched for that account.

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

When the correct tariff is created after traffic has already been processed, rates must be entered with effective_from set to the start of the service period — not today. Re-rating looks for a rate effective at the time of each call; if no rate was effective then, re-rating finds nothing. Currently, setting effective_from to a past date requires either a direct database UPDATE or running the update_effective_from.pl script on the server (see CDR-643). The goal is to allow the Billing Administrator to enter rates with a past effective_from directly in the Admin UI.
Current solution: Direct DB update (UPDATE Rates SET effective_from = '2025-01-01 00:00:01') or the server-side update_effective_from.pl script . The script was extended in MR125-4 to support grouped tariffs and multiple tariffs in one run. Neither approach is available to the Billing Administrator in the UI without PortaOne Professional Services involvement.

1. Finance team is ready to create tariff CUST_B_REAL_TARIFF for account CUST_B_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 entering rates.
2. Billing Administrator opens the tariff in Admin UI, selects all rates, and uses the new "Set effective_from" action. Enters date: 2026-03-01 00:00:00. System shows: "This will back-date effective_from for all N rates in tariff CUST_B_REAL_TARIFF to 2026-03-01 00:00:00. Confirm?"
3. Administrator saves the tariff. System stores all rates with effective_from = 2026-03-01 00:00:00.
4. Administrator runs re-rating for account CUST_B_Account1, time range 2026-03-01 – 2026-03-17, wrong tariff: DUMMY_TARIFF, correct tariff: CUST_B_REAL_TARIFF. System now finds applicable rates (effective from 2026-03-01) and re-rates all 2,340 XDRs successfully.

Expected result:

• All rates in CUST_B_REAL_TARIFF are saved with effective_from = 2026-03-01 00:00:00, entered directly at the time of rate creation without a subsequent back-dating step.
• Re-rating for account CUST_B_Account1, period 2026-03-01 – 2026-03-17 completes successfully: 2,340 XDRs re-rated with CUST_B_REAL_TARIFF rates. No "no applicable rate found" errors.
• No Professional Services involvement, server-side script, or direct database access required.

Use Case #2: Different Accounts Get Different Proper Tariffs

A customer has multiple accounts that were provisioned with shared initial dummy tariffs. Each account now needs to be re-rated with its own specific correct tariff, independently and without cross-account interference.

Use scenario #2.1: Sequential per-account re-rating, each with a different correct tariff

1. 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.

1. Administrator confirms. Job RERATE-20260320-XXXXX9 runs.
2. At 2026-03-20 09:11:14, job completes. 3,100 XDRs for account 4089 updated with CUST_A_ACC1_REAL_TARIFF rates.
3. 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.

1. Administrator confirms. Job RERATE-20260320-XXXXX1 runs.
2. At 2026-03-20 09:29:45, job completes. 4,872 XDRs for account 4121 updated with CUST_A_ACC2_REAL_TARIFF rates.

Expected result:

• Account 4089: 3,100 XDRs re-rated with CUST_A_ACC1_REAL_TARIFF. Charged amount change logged.
• Account 4121: 4,872 XDRs re-rated with CUST_A_ACC2_REAL_TARIFF. Charged amount change logged.
• No cross-contamination: each account's XDRs use only its own correct tariff.

Use Case #3: 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 #3.1: Re-rating filtered by rate code group

1. 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); Correct Tariff: "CUST_A_ACC2_REAL_TARIFF" (same tariff, rates corrected in-place).

1. Administrator confirms. Job RERATE-20260410-XXXXX runs.
2. At 2026-04-10 14:11:22, job completes. 1,247 XDRs updated.

Expected result:

• 1,247 XDRs for rate code group MEXICO MOB, account 4121, period Apr 1–9: charged_amount updated.
• 13,753 XDRs for other rate codes unchanged.
• Charged amount reduction: −USD 456.54.

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

1. Billing Administrator opens Re-rating wizard. Selects Customer: Customer A, Account: CUST_A_Account2.

• Expands Rate Code Filter section. Selects mode: Individual Rate Code. Enters rate code: "5215". Time range: 2026-04-01 – 2026-04-09.

1. Administrator confirms. Job RERATE-20260410-XXXXX runs and completes. 89 XDRs updated.

Expected result:

• 89 XDRs for rate code 5215 updated. All other XDRs untouched.

Use Case #4: 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 and re-sending of the XDR History Report CSV file.

Use scenario #4.1: Re-rating XDRs in a closed period; XDR History Report regenerated and re-sent

1. 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 INV-YYYY-MM-CUST). 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".

1. Administrator confirms. Re-rating Job RERATE-20260417-XXXXX starts.
2. At 2026-04-17 09:47:12, re-rating completes. 4,872 XDRs updated in closed period. Invoice totals for INV-YYYY-MM-CUST updated. Credit note CNV-YYYY-MM-CUST-CN1 for USD 427.83 generated.
3. System automatically triggers XDR History Report regeneration for INV-YYYY-MM-CUST. Job RPTREGEN-20260417-XXXXX produces "XDR_History_CustA_202603_revised_20260417.csv" and uploads to Reports archive, replacing the March file.

• System sends revised CSV to customer-billing@example.com with subject "[REVISED] XDR History Report – March 2026". Email body states: "This report supersedes the previously delivered March 2026 CDR report. Re-rating applied on 2026-04-17."

1. At 2026-04-17 09:49:55, Billing Administrator receives confirmation in Admin UI: "Re-rating complete. Report regenerated and re-sent."

Expected result:

• 4,872 XDRs updated in closed period INV-YYYY-MM-CUST (not duplicated in April open period).
• Charged amount: USD 3,241.88 → USD 2,814.05. Credit note CNV-YYYY-MM-CUST-CN1 for USD 427.83 issued.
• Revised XDR History Report available in Customer UI → Reports for customer 402.

• Email with subject "[REVISED] XDR History Report – March 2026" delivered to customer-billing@example.com.

Use scenario #4.2: Re-rating blocked when permission flag is disabled

Note: This scenario is included as a safeguard based on operational risk assessment (see BA-46682 for background on closed billing period re-processing complexity). There is no direct CSP request for a permission flag specifically; it is a proposed control mechanism. To be confirmed with the customer whether this access control is required before implementation.

• System setting "Allow re-rating in closed billing period" is DISABLED.

1. Administrator selects time range 2026-03-01 – 2026-03-31 (closed period). System shows error: "Re-rating in closed billing period is disabled. Contact your system administrator." Run button is disabled. No job is created.

Expected result:

• No XDRs modified.

Use Case #5: Deleting Imported XDRs (Rollback of a Collection)

A CDR 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 #5.1: Billing Administrator rolls back an erroneously imported collection via Admin UI

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

• Locates collection "f2026_02_01_edr_20260202_1103". Details: 8,021,440 XDRs, file F2026-02-01.csv, imported 2026-02-02 02:07:00. Status: ACTIVE.

1. 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?"
2. 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. Collection status → ROLLED_BACK.

1. 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 steps 2–6 for collection "f2026_02_02_edr_20260203_1106".

Expected result:

• Both collections status → ROLLED_BACK. XDRs deleted from OpenSearch and MySQL.
• Balances for 47 affected customers recalculated and corrected.
• Rolled-back collections remain visible in Admin UI with status ROLLED_BACK and rollback timestamp for audit purposes.
• Rolled-back collections cannot be rolled back a second time.

Use scenario #5.2: Rollback of a partial collection (specific XDRs only)

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

1. Administrator opens collection "f2026_02_01_edr_20260202_1103" → filters by Account: "CUST_C_Account". System shows 138 XDRs matching.
2. Administrator clicks "Delete Selected XDRs". System deletes 138 XDRs and recalculates balance for CUST_C_Account customer.

Expected result:

• 138 XDRs for CUST_C_Account deleted. Collection status remains ACTIVE (partial rollback). Customer balance for CUST_C_Account recalculated.

Use Case #6: Re-processing XDR Collections Including Successfully Rated XDRs

A billing parameter (e.g., MinimumCallDuration) was misconfigured at the time of collection processing. This cannot be corrected by re-rating (which only changes tariff rates). The collection must be re-processed with the corrected parameter, including XDRs that were already successfully rated.

Use scenario #6.1: Re-processing including successful XDRs for a specific account

1. At 2026-04-17 11:00:00, Billing Administrator navigates to XDR Mediation → Collections → "20250901_0502_279645800792062_0792".

• Clicks "Re-process Collection". In the re-processing options panel, enables toggle: "Include successfully processed XDRs".
• Applies account filter: "CUST_C_Account".lling parameters. 1,846 XDRs for other accounts excluded from scope."

1. Administrator confirms. Job REPROC-20260417-XXXXX starts.

• System re-processes 138 XDRs applying the corrected MinimumCallDuration=6 for account 3301. Charged_quantity and charged_amount are recalculated per XDR.

1. At 2026-04-17 11:04:22, job completes. System reports: "138 XDRs re-processed. Total charge delta: −USD 312.44 for account CUST_C_Account."

• Since the billing period is closed, system triggers XDR History Report regeneration for affected customer and period (as in Use Case #4).

Expected result:

• 138 XDRs for account CUST_C_Account: charged_quantity and charged_amount recalculated with MinimumCallDuration=6. Total delta: −USD 312.44.
• 1,846 XDRs for other accounts in the collection: unmodified.
• If billing period is closed: credit note issued for delta; XDR History Report regenerated and re-sent.

Use Case #7: Re-processing XDR Collections in a Closed Billing Period

All scenarios in Use Case #6 apply also when the billing period of the affected XDRs is closed. The re-processing updates XDRs in-place within the closed period, generates a credit note, and triggers XDR History Report re-sending.

Use scenario #7.1: Re-processing in a closed period with credit note generation

1. Same steps as Use Case #6, scenario #6.1. When Administrator selects the collection and account, system detects the billing period is closed and displays: "Warning: billing period September 2025 is closed. Re-processing will update XDRs in place. A credit note will be generated for the charge delta. XDR History Report will be regenerated and re-sent."
2. Administrator confirms. Job REPROC-20260417-XXXXX-CLOSED runs. 138 XDRs updated in closed period.

• Credit note CNV-YYYY-MM-CUST-CN1 for USD 312.44 generated for customer CUST_C_Account.
• XDR History Report for September 2025 regenerated and re-sent to customer's registered email.

Expected result:

• 138 XDRs updated in closed period INV-YYYY-MM-CUST. Credit note for USD 312.44 issued.
• Revised XDR History Report for September 2025 delivered to customer by email.
• Invoice INV-YYYY-MM-CUST is NOT reopened; only the XDR charges and the report are updated.

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

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

Use scenario #8.1: Billing Administrator configures daily CDR delivery for a customer

1. At 2026-04-01 10:00:00, Billing Administrator opens Customer "Customer A" → Reports → CDR Delivery Schedule.

• Clicks "Add Schedule". Sets: Frequency=Daily, Grouping=By Account, Format Template="CSP_Wholesale_v1", Destination Email=customer-billing@example.com, Delivery Time=06:00 UTC.
• Saves configuration. System confirms: "Daily CDR delivery enabled. First report: 2026-04-02 06:00 UTC."

Expected result:

• CDR Delivery Schedule record created for customer 402: frequency=DAILY, grouping=BY_ACCOUNT, email=customer-billing@example.com, time=06:00 UTC.

Use scenario #8.2: System automatically sends daily CDR report at scheduled time

1. At 2026-04-02 06:00:00 UTC, CDR delivery scheduler triggers report generation for customer 402. Job CDRRPT-20260402-XXXXX starts.

• System queries XDRs for customer 402 for the period 2026-04-01 00:00:00 – 2026-04-01 23:59:59 UTC. 18,442 XDRs across 6 accounts retrieved. Report grouped by account.
• CSV file "CDR_CustA_20260401_grouped_by_account.csv" generated. Sent to customer-billing@example.com with subject: "Daily CDR Report – 2026-04-01 – Customer A".

1. Job completes at 2026-04-02 06:07:14 UTC. Admin UI shows delivery status: SUCCESS.

Expected result:

• Email with daily CDR CSV delivered to customer-billing@example.com by 06:10 UTC.
• CSV file contains 18,442 rows, grouped by account, in CSP_Wholesale_v1 format.
• Billing period for customer 402 remains monthly; the daily CDR delivery does not create or close billing periods.
• Delivery log entry: date 2026-04-02, customer 402, XDR count 18,442, status SUCCESS.

Use scenario #8.3: Re-rated XDRs cause revised daily CDR report to be re-sent

• 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 CDR report for 2026-04-01 was already delivered on 2026-04-02.
• Upon re-rating completion, system detects that XDRs from 2026-04-01 were already included in a delivered daily CDR report.

• System regenerates the CDR report for 2026-04-01 and re-sends it to customer-billing@example.com with subject: "[REVISED] Daily CDR Report – 2026-04-01 – Customer A".

Expected result:

• Revised daily CDR CSV for 2026-04-01 delivered to customer-billing@example.com. Subject prefixed with "[REVISED]".

• Delivery log updated with re-send event and re-rating job ID.

Non-functional Requirements

Performance:

• Re-rating job for up to 50,000 XDRs: complete within 30 minutes.
• Re-rating job for up to 400,000 XDRs (full monthly CSP volume): complete within 4 hours.
• Collection rollback for up to 10 million XDRs: complete within 3 hours.
• Daily CDR report generation for up to 50,000 XDRs: complete within 15 minutes.

Availability:

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

Security and Access Control:

• Permission "Allow re-rating in closed billing period" – configurable per Admin role.
• Permission "Allow collection rollback" – configurable per Admin role; separate from re-rating permission.
• Permission "Allow re-processing including successful XDRs" – configurable per Admin role.
• Read-only roles must not see re-rating, rollback, or re-processing action buttons.

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.
• XDR History Report and CDR delivery email must include in header: report generation timestamp, "Revised: Yes/No", job ID if applicable.

Data Integrity:

• Re-rating / re-processing in a closed billing period must not change bill_status. A credit note is generated automatically for the delta.
• Collection rollback is irreversible (XDRs deleted, not archived). System must require explicit name-confirmation from administrator before executing.
• 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.

Peculiarities

Assumptions:

• Re-rating at i_account level means the wizard filters XDRs by i_account in addition to i_customer and wrong tariff. This prevents cross-account contamination when multiple accounts share an initial dummy tariff.
• "Re-processing including successful XDRs" means the re-processing engine does not skip XDRs with status=SUCCESS, and re-applies current billing parameters (e.g., MinimumCallDuration) from scratch. The previous charged amounts are overwritten.
• Collection rollback deletes XDRs permanently from OpenSearch and MySQL. Rolled-back collections are retained as metadata records (status=ROLLED_BACK) for audit purposes.
• Credit note generation upon re-rating/re-processing a closed period follows the existing credit note workflow. If the invoice has not yet been issued, only XDR charges are updated.
• Daily CDR delivery is decoupled from billing period: the scheduler generates a report for yesterday's 24-hour window each morning, regardless of billing period boundaries.

Constraints:

• Account migration (move_account / transferring XDRs between customers) is out of scope for this BRS. That scenario is tracked separately.
• Traffic Attribution (associating unallocated XDRs to i_account when no tariff match exists) is out of scope. Tracked as .
• Re-rating by arbitrary SQL filter or regex is not in scope. Filters supported: i_account, rate code group (by ID), individual rate code (exact match or starts-with).

Open Questions:

1. Q1: Should credit notes require Billing Administrator approval before generation, or be automatic? (Assumed: automatic for re-rating delta; to confirm with CSP.)

• Q2: For collection rollback of 8+ million XDRs: should balance recalculation be real-time or deferred to next billing run? (To confirm with CSP — performance trade-off.)
• Q3: When a daily CDR report is revised after re-rating, should the original file be retained in the delivery log alongside the revised one, or replaced? (Assumed: revised file replaces original in Customer UI; original retained only in delivery audit log.)
• Q4: Maximum historical depth for re-rating in a closed period: any period in the last 12 months, or only the immediately preceding period? (To confirm with CSP.)