Skip to content

Intercompany Activity: Priorities & Context

Date: 2026-02-08 (updated 2026-02-17) Domain: IC Activity

Priority Ranking

Based on customer validation and urgency, here's the order of IC jobs to tackle:

Top Priority (Confirmed - 2+ sources)

1. Differentiate automatic pool sweeps from intentional IC payments - Sources: ON + Palm Internal (Confirmed) - Current status: Partial (Cash Pooling feature exists, but no automatic sweep classification) - Why it matters: Teams spend time investigating why money moved, confusing ZBA sweeps with actual payments. This is foundational — if we can't tell sweeps from payments, nothing else makes sense.

High Priority (Emerging but recurring)

2. Monitor IC payments across global entities to detect failures - Source: ON ($8M Canada payment failure, Feb 4 2026) - Why it matters: This is an outcome problem, not just visibility. Failed payments go unnoticed even by regional teams, causing doubled-up catch-up payments and cash flow chaos. - See case study below

3. Accurately categorize IC transactions by type - Source: Palm Internal - Gap: Misidentifies as FX or ZBA instead of proper IC type; can't determine cost plus vs dividend vs loan from transaction descriptions - Why it matters: Foundation for everything else — if categorization is wrong, downstream analysis breaks

4. Separate capex funding from operational IC - Source: ON (Feb 4 2026) - Gap: Can't set up IC loan contracts because don't know how much capex was funded via cash pool - Why it matters: Entities can't pay back short-term, need separate IC loan structure; affects legal entity financing strategy

Medium Priority (Important but less urgent)

5. Understand entity funding needs vs incoming cost plus settlements - Source: Palm Internal - Gap: Treasury makes funding decisions without knowing AP is about to kick off a $5-20M settlement - Why it matters: Prevents unnecessary funding transfers; improves capital efficiency

6. Forecast IC cash flows with correct timing - Source: Palm Internal (Personio example: monthly IC payments forecast weekly) - Gap: Timing attribution wrong, not treating ZBA sweeps as calculated vs predicted - Why it matters: Entity-level variance looks wrong without IC forecast; "the forecast will look very wrong if you see just a balance"

The Pattern: Two Streams

Stream 1: Categorization & Classification (jobs 1, 3)

If we can't identify what type of IC transaction it is, nothing else works. This is foundational. Need to solve: - Is this IC or not? - If IC, what type? (sweep, cost plus, dividend, loan, equity) - Is it automatic or intentional?

Stream 2: Monitoring & Decision Support (jobs 2, 4, 5)

Once categorization works, surface the insights treasury needs to act: - Failed payments that went unnoticed - Capex funding amounts for IC contract setup - Upcoming settlements to inform funding decisions - Regional visibility so local teams can monitor their own entities

Case Study: The $8M Canada Payment Failure

Date: February 2026 Company: On Running Source: Daily Standup 2026-02-04

What happened

An $8 million intercompany payment from Canada to another On entity failed to execute. Nobody noticed: - Not central treasury - Not the Americas regional team - Not Canada local finance

The payment was supposed to go out that week, but didn't. The following week, Canada had to pay $16 million (the missed $8M + the current week's $8M).

How it was discovered

The Americas team only realized something was wrong when they saw the payment amount:

"How can we pay 16 million this week? It's double what we usually pay."

They had to investigate backward to figure out the previous week's payment had failed. There was no proactive alert. They discovered it reactively because the amount looked wrong.

Why this matters

This is a monitoring gap, not a forecasting gap: - The payment was supposed to happen (it was in the plan) - It failed to execute (operational failure) - There was no system alerting anyone that it failed - Even when balances were unexpectedly high, there was no connection to "a payment failed"

The broader context

This story came up in a meeting where On was discussing: 1. Entity-level access control being built for regional teams 2. Scheduled PDF reports for regional finance teams 3. Expanding Palm access beyond central treasury to APAC, Americas, EMEA regional contacts

The implication: if On is going to give regional teams access to Palm, those teams need to be able to monitor their own IC payments and get alerted when something goes wrong. Central treasury can't catch everything manually.

Technical Challenges

Categorization is hard because:

  1. Two-level problem: First determine if it's IC, then what TYPE of IC
  2. Transaction descriptions lack data: Don't indicate if payment is tax, interest, dividend, loan
  3. Terminology confusion: "Internal transfer" (same entity, different accounts) vs "Intercompany" (different legal entities)
  4. Misclassification: System confuses IC with FX transfers or ZBA transfers

Monitoring is hard because:

  1. No baseline for "expected" payments: What's normal vs abnormal for each entity pair?
  2. Regional decentralization: 3 regional treasury contacts, each covering multiple entities
  3. No proactive alerting: Only discover issues when balances are unexpectedly high/low

Next Steps

  1. Validate IC monitoring demand with other customers (is $8M Canada story unique to On, or common pain?)
  2. Design IC payment monitoring dashboard MVP (what's the minimum viable alert?)
  3. Improve IC categorization accuracy (foundational — needed before monitoring makes sense)
  4. Entity-level access control (enables regional teams to own their IC monitoring)