By service — which entities are billed
Pick a service charge to see every entity billed for it, ranked by value, with the initiator income GL and receiver expense GL that carry it. Toggle to see which entities initiate the charge.
Initiator books income · 720/721xxx
Receiver books expense · 660/661xxx
Pluto = non-Oracle customer (invoice-level, budgeted FX)
Services — by value
By initiator — who bills whom
Pick an initiating entity, then open a receiver to see the services billed and the GL accounts used.
Initiators — by value billed
Service → GL reference
Every service maps to a Shared-Services income GL on the initiator side and a matching expense GL on the receiver side. Search by service name or GL code.
| Service | Source | Value (USD) | # Entities | Initiator GL · income | Receiver GL · expense |
|---|
Key findings & recommendations
Based on the Jan–May 2026 recharge data mapped above ($73.75M across 3,233 flows). Figures are computed directly from the dataset behind this page.
Key data facts
- $73.75M mapped over 5 months — 74% ICSB (Oracle-native, $54.9M) vs 26% Pluto (non-Oracle, $18.85M).
- 3,233 flows across 12 initiating entities, 184 receiving entities and 240 service items — 431 distinct initiator→receiver relationships.
- Top 8 entity pairs already carry ~43% of total value; the single largest service (PROFESSIONAL ADHOC SERVICE) is 7.3%.
- 16.5% of total value ($12.2M) is entities billing themselves (same legal entity as initiator and receiver) — worth validating this is intentional cross-BU allocation, not a mapping artifact.
- Pluto service items required remediation this session (were showing GL account descriptions, not real service names). 71% of Pluto value still comes from invoices that bundle 2+ services under one blended amount — the source system doesn't capture a per-service split.
The volume vs. materiality trade-off
- Charging every cost, at transaction level, is what drives the flow count from hundreds to thousands as the business scales — more invoices to raise, GL-map, and reconcile every month.
- The data shows this growth is concentrated in low-value transactions: 61% of flows (1,973 of 3,233) are each under $5K and together are only 3.6% of total value.
- 72.5% of flows are under $10K, representing just 7.2% of value. Conversely, the top 72 flows (2.2% of count) already make up 50% of value.
- So full transaction-level granularity buys very little additional financial accuracy over a materiality-based approach, at a real cost in processing effort and audit risk as volumes grow.
Best practices for intercompany / intracompany billing
- Materiality threshold. Set a de minimis $ level (e.g. OECD's simplified approach for low value-adding intra-group services) below which costs are pooled into a monthly cost-allocation fee instead of itemized per transaction — costs are still fully charged, just not individually invoiced.
- Standardised service catalog. One master list of service items with a fixed GL mapping, shared by every source system (Oracle and non-Oracle alike), so recharges never fall back to a raw GL code or account description.
- Batch and net. Consolidate repeat charges to the same receiver into one monthly line; net reciprocal flows between the same two entities where tax/legal treatment allows, to cut gross transaction count without losing net value.
- Fixed-fee / SLA billing for predictable services. Recurring items (software licenses, standard support) work better as a flat monthly fee than as ad hoc itemized charges.
- Automate the GL-to-service mapping. Manual, spreadsheet-based mapping (what produced this session's Pluto data-quality issue) doesn't scale with transaction volume — automate capture of the real service item at source.
- Transfer pricing documentation. Keep intercompany agreements, benefit tests and allocation keys current and OECD/BEPS-aligned, particularly for low-value services charged via a pooled allocation rather than line-by-line.
- Periodic true-up. For budgeted-FX or estimated charges (as Pluto uses), true up quarterly against actuals rather than adjusting every individual transaction.
Recommendation: adopt a materiality threshold (data suggests roughly $5K–$10K per service-pair/month is a reasonable starting point) below which costs are pooled into a standard monthly allocation rather than itemized individually. On this dataset that would remove ~61–73% of transaction volume while still fully recovering 93–96%+ of total value — satisfying "charge all costs" in aggregate while directly addressing the complexity growth. Pair this with fixing Pluto's data capture at source and automating the GL-to-service mapping, so the trade-off doesn't have to be re-litigated manually every time volume grows.
Worked example: materiality threshold in practice
The single worst offender in this dataset: MCT FZE → Michel Chalhoub Trading Co. L.L.C. is billed as 39 separate service lines every month — every one of them under $5K/month.
| Service (top 5 of 39) | 5-mo total | /month |
|---|---|---|
| CORPORATE TAX & TP | $15,600 | $3,120 |
| HR SERVICES/HEADCOUNT/MONTH | $11,935 | $2,387 |
| PROFESSIONAL ADHOC SERVICE | $9,714 | $1,943 |
| ORACLE RETAIL/USER/MONTH | $8,726 | $1,745 |
| DATA INTEGRATION SERVICES/BY INBOUND OUTBOUND MESSAGES | $7,383 | $1,477 |
| …34 more, down to… | ||
| SUPPLIER SITE / CUSTOMER SITE - MAINTENANCE | $4 | $0.80 |
Total: $122,367 over 5 months = $24,473/month. Someone is currently GL-mapping and reconciling an invoice line for 80 cents a month.
Proposed fix: one pooled line — “Shared Services Allocation — Michel Chalhoub Trading Co.” — billed at $24,473/month. Same entity, same total recovered, 39 lines → 1 line, zero dollars lost.
Scaled across the whole dataset ($5K/month threshold)
| Count | Value | |
|---|---|---|
| Flows below threshold | 2,733 of 3,233 (84.5%) | $12.15M (16.5%) |
| Collapses into | 405 pooled lines/month | same $12.15M, fully recovered |
That's 85% fewer monthly line items, with the $ impact staying invisible to the P&L — every cost is still charged, just not itemized down to the last dollar.
How the mechanism works
- Unit of pooling = initiator→receiver pair, not individual service. For each pair, any service below the monthly threshold is summed into one "Pooled Shared Services Allocation" line; anything already above threshold stays itemized as-is.
- One GL pair for the pool (e.g. a dedicated 7201xx/6601xx "Shared Services — Allocated" account) instead of dozens of individual service GLs — this is what actually removes the reconciliation burden.
- Quarterly threshold review. A service that grows past the threshold graduates back to its own line, so the pool never quietly hides something that's become material.
- This is the OECD-sanctioned approach, not a workaround. BEPS Action 8-10's simplified method for "low value-adding intra-group services" explicitly allows a pooled cost-plus-5% charge below a materiality threshold, with no per-transaction benefit test required — that's the transfer-pricing cover for doing this.