How they use it: Primary tool for bridging calculations - aggregate classified transactions, compare to budget EBITDA, derive working capital movements
Limitations: Manual, error-prone, no audit trail, doesn't scale
How they use it: Daily invoice upload → accept/reject based on credit insurer (Atradius) limits and age (>90 days penalized) → daily payout
Limitations: Access typically for accounting only; no API for factoring division; customer-level data only visible inside platform; Matthias still waiting on access token after 3 months
What it is: ON's FP&A platform — produces P&L, balance sheet, and a derived direct cash flow forecast through a hand-built translation layer (rules + maintained tables)
How they use it: FP&A plans P&L + BS structural items (sales, COGS, freight, customs) using accounting logic. Treasury (Lucia and predecessors) built the translation rules: assumption tables for AR aging splits, VAT timing, payment terms, plus calculations for items like the inventory→COGS→cash chain.
Limitations: Tables require constant maintenance and re-justification each cycle. The inventory→COGS detour is structurally complex. Translation logic isn't validated against reality — Lucia hasn't yet run variance analysis to check accuracy. FP&A doesn't actually use the cash-flow output (only P&L + BS). Lucia wants to replace the rule-based logic with Palm's model-driven inference and pitch the result back as official.
How they use it: Hub for all financial data — Dynamics actuals, AR/AP tables, the long-term FP&A plan, and Palm output
Limitations: Palm currently has access only to the AR/AP table; full bidirectional connection (especially for the long-term plan) is the desired next step. Lucia framed Palm ↔ data lake as the architectural backbone of the "low-touch" treasury vision.
What it is: Kyriba — treasury operations (payments, FX, repatriation). Looker — reporting layer fed by the data lake.
How they use it: Lucia's three-tool ecosystem: Palm (forecasting + categorization) + Kyriba (operations) + Looker (reporting). All other operations should disappear into the data lake.
Limitations: Mentioned only as the target architecture, not currently fully realized.
What they do: Treasury manually maintains tables in Anaplan for AR aging splits per company (e.g., 70% within one month), VAT timing assumptions, and inventory turnover. Each forecast cycle, treasury reviews and re-justifies why each value is what it is.
Why: Anaplan's bridge translation is rule-based; tables capture company- or category-specific assumptions the rules need to convert P&L into cash. Without maintenance, the translation diverges from current payment behavior.
Source: ON (2026-04-29) — "Every time that if I have to update this, I'm like, okay, why did we assume this again? And I have to review it all the time."
What they do: Treasury opens Palm's forecast in one window and the long-term Anaplan plan in another (or pulls both into Excel) to gut-feel whether they tell the same story for the long-term horizon
Why: No automated bridge between Palm's bottom-up cash forecast and FP&A's top-down P&L plan; treasury needs the comparison as a "second tick in our head" before acting on the forecast