Skip to content

ON - Direct / Indirect Bridging - 2026-04-29

Metadata

  • Date: 2026-04-29
  • Company: ON
  • External Participants: Lucia Galan-Cáceres (Group Treasurer / Head of Treasury)
  • Palm Participants: Emma Sjöström, Gurjit Pannu, Graciela Hernández Rodriguez (new design lead, first customer call)
  • Type: Customer Call
  • Domain Areas: Bridging, Cash Forecasting
  • Recording: https://tldv.io/app/meetings/69f1b3c5f4ca130013471e4f

Summary

Context

First conversation with Lucia (recently appointed Group Treasurer at ON) focused on the direct/indirect bridge. ON's FP&A team builds P&L + balance sheet forecasts in Anaplan, with a manually-maintained rule layer that translates indirect plans into direct cash flow. Lucia wants to assess whether Palm could replace that rule logic with ML-driven bridging. Emma demoed the early bridging prototype towards the end. Graciela (new Palm design lead) attended as her first customer call. Emma also flagged that she is leaving Palm on May 22, 2026.

Key Discussion Points

  • Two-tier validation framework (Lucia's mental model): "There are two ways of telling if a forecast is good. First, the variance analysis [Palm's forecast vs Palm's past actuals]. The other one... we call it plausibility check [Palm's forecast vs controlling's long-term plan]." The bridge converts the plausibility check from a manual gut-feel exercise into a data-driven one. This framing is the spine of how Lucia evaluates the bridge prototype.
  • ON's bridge today: Anaplan-based, rule-driven translation of P&L/balance sheet into direct cash flow. Built jointly with FP&A. Mix of calculation rules (self-sustaining) and hand-maintained tables (high-touch). Concrete examples Lucia showed: VAT assumptions, AR aging splits per company (e.g., "70% within one month"), inventory→COGS→cash detour for warehouse payments.
  • Lucia's hypothesis: top-down (FP&A) and bottom-up (Palm) will tell two different stories — that's fine, they serve different purposes. They don't need to match, but they need to go in a similar direction.
  • Time-horizon split:
  • ≤13 weeks: Palm forecast = source of truth (operational, treasury-driven). Long-term plan should NOT bias the short-term operational forecast — "you come up with a better forecast by ignoring the long term in the short term."
  • >13 weeks (especially >6–7 months): FP&A long-term plan = source of truth. Palm should incorporate it as a high-quality assumption. "The longer term we go, the higher the weight of the forecast from controlling takes."
  • Controlling's plan is binding even when individuals disagree. Lucia: "I can look at the sales and say, hey, this is completely unrealistic. But hey, sales team said that. So. Okay." Once a number is consolidated into the plan, it's the source of truth. This shapes how Palm should present the bridge — not as "your plan is wrong" but as "here's the gap, here are possible drivers."
  • Lucia's larger ambition: replace Anaplan's translation logic entirely with Palm. "I would be happy to pitch this back to the FP&A team and say, can we treat this as official?" Specific test case: skip the inventory→COGS→cash detour and infer warehouse cash payments directly from sales patterns. Statistics may do a better job than the hand-coded chain.
  • Bridge persona is explicitly cross-functional. Lucia: "this role who uses this is a bit blurred because it's a conversation that's probably half treasury, half controlling." Concrete use case: treasury → APEC region conversation ("APEC is always off because we grow faster than expected"). Tertiary user: CFO ("I want to understand how my P&L transforms into [cash]").
  • "Low / no touch treasury" vision — three tools only: Palm (forecasting + categorization), Kyriba (operations: payments, FX, repatriation), Looker (reporting). Everything else flows through the data lake (BigQuery). Palm's role: quietly produce the forecast, surface alerts only when something is off. Override path always available ("nah, let me type in five instead of two").
  • Variance drivers are often combinatorial (multiple causes at once). The variance feedback loop should support ticking multiple drivers, not single-cause selection.
  • Bidirectional Palm ↔ ON data lake required: ingest long-term FP&A plan + ERP transactions, push forecast back to Kyriba and downstream systems.
  • Long-term plan refresh cadence: every ~3 months. Available in BigQuery. Manual upload acceptable as a v0 starting point.
  • Pilot opportunity: ON already maps to the same categories as Palm. Lucia volunteered ON to test the tool's boundaries — start with their Anaplan-translated direct cash flow (easy case), then indirect with same categories, then raw P&L (find the limits).

Pain Points

  • Anaplan bridge logic is rule-based + table-driven → high maintenance (every assumption update requires re-justifying it).
  • Inventory → COGS → cash translation in Anaplan is "super complex" — Lucia thinks correlations between KPIs could replace it.
  • FP&A doesn't actually use cash flow forecasts (only P&L + balance sheet) — treasury maintains the bridge alone.
  • Plausibility-checking the forecast against the long-term plan is currently manual (Excel / Anaplan side-by-side).
  • APEC region consistently overshoots its forecast — controlling challenges them but the gap repeats every cycle.
  • Variance investigation is manual: when actuals deviate from plan, treasury digs for reasons one by one.
  • Trust hurdle: until Palm exposes its reasoning, controlling will resist using its numbers as official.

Feature Requests & Needs

  • Bridge view: budget / indirect plan plotted alongside actuals + Palm forecast, by category.
  • Variance explanation: for each visible delta (e.g., customer collections lagging), surface candidate drivers — slow payers, FX, one-offs, performance gaps. Make them tickable.
  • Variance feedback loop: user can confirm the cause + leave a comment; that confirmation feeds the model so future similar variances are pre-explained.
  • Historical bridge view: filter to a past period and see prior commentary / decisions ("here's what we concluded six months ago").
  • Long-term plan ingestion from BigQuery, refreshed each forecast cycle (~quarterly).
  • Manual upload fallback for the long-term plan as a starting point before BigQuery integration.
  • Boundary testing: support uploads at three levels of granularity (direct cash flow, indirect with same categories, raw P&L) to find where the model breaks.
  • Explainability surface ("Gemini-style reasoning"): show the steps Palm took to produce a number — assumptions, references, the calculation path. Required to earn controlling's trust.
  • FX & cash-position alerts: Palm should flag short cash positions in specific currencies/regions (e.g., "you're short USD because cash is sitting in China") — drives the repatriation conversation. Treasury then acts in Kyriba.
  • Categorization prompts for refinement — same UX pattern Lucia wants for variance feedback.
  • Out of scope (for now): payment generation flowing from Palm to Kyriba — Lucia agrees that's a different beast.

Jobs & Desired Outcomes

Lucia frames forecast confidence as standing on two legs: variance analysis (Palm's forecast vs Palm's past actuals) and plausibility check (Palm's forecast vs controlling's long-term plan). The bridge is fundamentally an automated plausibility check, plus a surface for explaining the gaps it reveals, plus a longer-term ambition to replace ON's manual translation logic.

Job 1: Plausibility-check Palm's cash forecast against controlling's long-term plan. Today this is a manual Excel/Anaplan side-by-side. The bridge replaces that manual step. Lucia: "you're reducing an activity that is very high touch... allowing us to do that second tick in our head of like, oh yeah, in line with what controlling is saying — second reason to believe this is a good forecast and we can act on it."

Desired Outcomes: - Reduce the time treasury spends manually comparing Palm's forecast to the long-term plan in Excel/Anaplan - Increase treasury's confidence that the forecast can be acted on without a separate side-by-side validation against controlling's plan - Reduce the friction with controlling when treasury proposes acting on Palm's forecast ("you're not taking our numbers") - Surface entity- and currency-specific shortfalls revealed by the bridged balance-sheet projection (e.g., short USD because cash is sitting in China — Lucia: "Palm already has the projection. So you can tell us where we're short for the balance sheets")

Job 2: Explain why Palm's cash forecast diverges from the long-term plan. For each visible delta in the bridge, surface candidate drivers and let treasury confirm them. Drivers are often combinatorial — Lucia: "It can be a combination of three big customers paying late plus, I don't know, something happened in the bank." Confirmations should both persist (so the same investigation isn't repeated) and feed back to the model (parallel to categorization prompting).

Desired Outcomes: - Increase the speed at which treasury identifies the most likely driver of a variance - Reduce the time treasury spends investigating variance drivers across systems and Excel - Persist confirmed explanations against past bridge periods, so the same investigation isn't repeated 6 months later - Improve the precision of future variance explanations by feeding confirmed causes back into the model

Job 3: Reduce the maintenance burden of the rule-based indirect-to-direct translation. ON's Anaplan bridge today is calculation rules + hand-maintained tables (AR aging splits, VAT timing, the inventory→COGS→cash detour). Tables need constant care; assumptions need re-justifying each cycle. Lucia: "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." She wants Palm to do this with model-driven inference from historical data instead.

Desired Outcomes: - Reduce the number of hand-maintained assumption tables required to translate plan into cash (AR aging splits, VAT timing, payment-term tables) - Reduce the time treasury spends re-deriving or justifying bridge assumptions in each forecast cycle - Decrease the structural complexity of the bridge by replacing rule chains with statistical inference (e.g., infer warehouse cash payments directly from sales patterns, skipping the inventory→COGS detour)

Domain Insights

  • ON's stack: Microsoft Dynamics (ERP) → BigQuery data lake → Anaplan (FP&A planning) + Palm (cash forecasting) + Kyriba ("k") (operations) + Looker (reporting).
  • ON's FP&A produces P&L, balance sheet, and a derived direct cash flow forecast in Anaplan, refreshed quarterly.
  • Two-tier validation framework for treasury-side forecast confidence: (1) variance analysis = Palm's forecast vs Palm's past actuals (looking back); (2) plausibility check = Palm's forecast vs controlling's long-term plan (looking forward). Both legs are needed before treasury commits to acting on a forecast. The bridge automates leg #2.
  • Anaplan bridge logic = mix of calculations and maintained tables. Calculations are self-sustaining. Tables require constant care: each forecast cycle, treasury must re-justify why each assumption is what it is. Concrete examples: AR aging splits per company (e.g., "70% within one month"), VAT timing assumptions, inventory→COGS→cash chain (with payment-time tables).
  • The inventory→COGS detour is a deliberate accounting bridge: P&L recognizes COGS at the point of sale, but cash is paid for inventory bought earlier. Anaplan models this as inventory movement + payment time. Lucia thinks Palm could replace it by inferring warehouse cash directly from sales growth patterns.
  • Forecasting at ON is a "science and art" mix. Lucia distinguishes the team's view: "some people will say multipliers, and people will say, let me look at the sign contracts." Once consolidated, the plan becomes binding even for skeptics — collaborative consensus locks in the source of truth.
  • Regional teams (APEC, etc.) do not maintain their own forecasts — planning is centralized at HQ. Controlling challenges regions on their actual-vs-forecast P&L; treasury could extend that conversation to cash.
  • Lucia's "no touch" vs "low touch" distinction: no touch = model runs autonomously, user just confirms; low touch = user can override an assumption when they have specific knowledge ("let me type in five instead of two"). She wants the day-to-day to be no-touch, with the override path always available for special-knowledge cases (e.g., a celebrity collab driving sales, or a one-off market event).
  • Trust prerequisite: explainability. Lucia uses Gemini-in-Sheets as her reference — the tool shows what it's doing step by step, so she can validate the reasoning. Without that, treasury (and certainly FP&A) won't adopt Palm's numbers as official.

Action Items

  • [ ] Lucia to share Anaplan liquidity planning essentials deck (was Amanda's, to confirm reuse)
  • [ ] Palm to scope BigQuery integration for long-term plan ingestion
  • [ ] Manual upload path for the long-term plan as a v0
  • [ ] Graciela to dig into PostHog + with Giannis for product context
  • [ ] Follow-up on FX cash flow monitoring as a separate workstream

Notable Quotes

"There are two ways of telling if a forecast is good. First, the variance analysis... and the other one, that normally we do off Palm — and it's more of a gut feeling, we call it plausibility check — is, does my forecast more or less match what controlling is saying we're going to hit? This is what you're bringing here with data instead of a gut feeling." — Lucia (the conceptual foundation of how the bridge fits into her workflow)

"I really want to create this high value low touch treasury. Wherever we are not needed to touch anything and we can rely on a product." — Lucia

"What's interesting here is to test the boundaries of the tool... What if instead of giving you the direct, I give you the indirect? What if I go one step further and I give you just the P&L? How good is it?" — Lucia

"On a regular day, I would love forecast to be more science than art... But I always want to have the option to go in and say, nah, let me type in five instead of two just because something I heard or something I want to simulate." — Lucia

"It just creates friction in the conversation with controlling when they say, yeah, but you're not taking our numbers. We want to speak the same language for the long term." — Lucia

"I think we might be a good pilot customer because we already follow the same categories across platforms. So this would be a very easy case for the tool to do the comparison." — Lucia

"I want exactly that — and I need visibility. So even in the no-touch version, I also need to see how you come to that number. The variance tool needs to have much more information for me to be able to fully trust your approach." — Lucia

Full Transcript

Me: Hello.
Them: Hey, how are you?
Me: Good. Thank you. How are you? Nice. I'm gonna start untildv.
Them: Okay.
Me: It's a bit slow. But should get started. So.
Them: Hello.
Me: Hi. Morning.
Them: Nice to meet you, likewise, Lucia. I'm good. Very busy. And I'm now boarding since we have a lot of handovers and stuff like this. But. You know, and you have was there offside. It looked great in pictures. It was amazing. I didn't know what to expect, but I was really. It exceeded my expectations. I'm so happy and willing to jump into the team. Now. Oh, you just joined Palm. Was it? Yeah, I joined, like, two weeks ago or. Yeah, week and a half. So I'm still. Wow. That's a nice onboarding. Yes, I thought the same. Very cool.
Me: Yeah, I unfortunately didn't go on the offside this time. And. I think it might as well just tell you that I'm leaving Palm, actually. Yes. It's my decision, so it's nothing like that. It's just. I don't know if you know, but I'm technically a consultant at Palm.
Them: Didn't know.
Me: No. So I like. I run my own consultancy.
Them: Okay.
Me: In tech and product, and I just want to. Explore some other opportunities that I have.
Them: That's fair.
Me: And, yeah, I really, really love Palm. Like, I stayed way longer than I. Than I originally intended. So.
Them: No, that's really cool. But I understand. I mean, if you, you know, seeing different things, and at some point you want to see different things.
Me: Yes.
Them: Not the same thing all the time. So that makes total sense. But I'm sure Gurjit and Christian are happy that they managed to keep you for so long. And sweat.
Me: Yeah.
Them: Okay.
Me: I think so. It's all good. But, yes, it's a bittersweet thing. But. I'll be honest for about a month. So until May 22nd.
Them: Okay. Then please, if there's anything we can do to ease, I mean, will you take over then, Graciela, the product? Management? Will that be the transition? Or part of it? But I think that the product management would be. But yes, I will be taking over more of, like, the design overview and the strategy of it. Okay, cool. Well, just let us know how we can help to ease that transition from all sides. Yeah.
Me: We'll be stepping up more on product as well. So he will likely be more involved as well. So I think that is.
Them: Okay, so it's. It's time for all of us to step up with you. And, Amanda, leaving, then all of us have to come. All good. I was. This is the one thing I'm not unhappy about because I had anyways in my to-do list that big block time for Palm reminder. And when Amanda told us that she was leaving, I said, okay, well, then now I really have to do it. So this is definitely an upside if there are any of people leaving the team.
Me: Yeah.
Them: So.
Me: That's true. Oh, well. We got that out of the way, which is good. But still, I am excited to talk about the direct and indirect bridging. We do have, or like, we do have super basic prototype, but I would like to wait with that and show that. Discuss that more towards the end of the meeting. And then, like, I'm super keen. To start with just hearing you.
Them: Yep.
Me: Tell us. Like, what is. Let's start super broad.
Them: Yep.
Me: When we say, like, bridging the direct and indirect budgets, what do you think? Of.
Them: So it's. I'm actually. The timing is perfect. For us. Because. So right now we. Our fpna, so financial planning analysis team creates. Forecast for the P and L for the balance sheet and also to for cash flow in annu plan. Right. And we worked with them on doing exactly that bridge within anaplan. So we gave between the two teams, we created the rules of how to translate p l forecast, especially and also balance sheet into direct cash flow forecast. So we have both indirect and direct. And that's great. I mean, we still haven't validated how good that is. So that's first, I'm validating them, or we're working on the forecast variants for. For Palm's forecast. Right. And k. And then we want to move on to anaplan, but it's there. So it's created in theory. We have it. But my expectation when I do the variance analysis is that it's going to be quite far from reality. And especially, I think since that's really a top down forecast, when I try to join Palm's bottom up forecast with that one, I'm expecting that they're going to two completely different stories. It's not necessarily wrong because for me, the. The long-term forecast serves a completely different purpose than the short-term one. So I don't need them to match exactly in the middle.
Me: That? Yep.
Them: But I do think they need to go on a similar Direction. And this is where I'm a bit afraid when I stood doing that variant. So I actually was telling the team. I think for the long term, so for the short term, I want to use Palm's forecast as the source of short-term forecasting truth. For the long term, I think we always have to refer back to the fpna plans just because that's the language that we agree in the organization. Hey, that's the future. So. So I think whatever plan we do, whether it's the ana plan or a different one, it needs to start from that point. But I would love, I also told the team I am because we spoke about you looking into this. I said, I would be excited to see how you, what you come up with and challenge our own unaplan logic based on this and eventually potentially say, hey, can we trust this one instead? So replacing that. Right. Because what we have in anaplan is very rule based. And that means lots of Maintenance. And if we could create a more intelligent logic with Palm, then I would be happy to pitch this back to the fpna team and say, can we treat this as official? Right.
Me: Gotcha. So even using Palm input or even the Palm forecast in the official.
Them: I would love that. I mean, the reality is that fpna doesn't really use cash flow forecasting. They just have the P l and the balance sheet. But if I can did the other one kind of for us, right? So we use that. But if I can say, hey, do you mind if I actually take your data, drop that logic, give it to Palm? Palm gives us the, the long-term indirect to direct both no statements we could have from Palm. And if, if they understand the logic and they can also say, hey, that's good enough for us and they can use it too, then even better. I mean, I just, you know, replaced rules by logic.
Me: Of course.
Them: Which to me is way to go.
Me: That makes sense.
Them: I.
Me: Yeah, I have a question, like, regarding. So if we look at. So Palm looks at cash.
Them: Actually.
Me: In your fpna team in any plan. Like they. You mentioned different types of. You have your P l and you have, like, your different types of forecast job. How different is it in, in your forecasts at Pna teams forecast? Like, do they use, like, recorded, like, data from the books? Passed, and then they sort of sort of create their assumptions based on the stuff like time of sale rather when cash hit the account. Like, I'm just trying to understand, like, these differences, these drifts. So the timing drifts, that might be. Something. Or, like, it's not a. Because you have different channels for sales, right? Direct to consumer. You have your. So just. Does it make sense where I'm going with this?
Them: Yes. I would be happy. Let me try to see if I can find. The ann plan. Do we have, I think, Amanda had the presentation on an applied logics. I could share it with you. So in anaplan, I mean, we have. The actuals that come from, from Dynamics, from the ERP, like the reports for the actual transactions. And then they do plan based on P and L and balance sheet structural items. So sales and cost of sales and freight and customs and. For this they use, like you said, the revenue recognition point or the point that we have to recognize cost. So it follows more on accounting logic. And that's how they forecast or they plan the P and L and the balance sheet. And what we do is we created assumptions and calculations of how to translate those items into cash. So exactly by looking at how fast accounts receivable turn into cash in the past. So we, we kind of Define kpis that allow us to do that transformation of financial planning into cash flow planning. I'm trying to find. Okay, here we go. I'm trying to see if we have anything. I could be interesting. Yeah. So I think I would, I will check with, with Amanda, but probably I can share this with you. So she prepared this liquidity planning Essentials just to understand how the planning and anaplan works. So, for example, for the debtors, that's the sales. So it's projecting customer cash flow starts with the yearly sales plan broken down into monthly targets and the calculation tracks two distinct sources. So existing receivable sales that were already made and need to be cashed in. So the outstanding balances are analyzed and estimated are determined based on historical payment terms. And then the cash generation from new sales. Right. So the sales will generate receivables and then how the receivables convert into cash. So all of these rules, sometimes there are calculations, sometimes they are a table that we maintain with hard coded facts.
Me: Okay.
Them: Are the ones that help us project the cash. But again, this is the rule, the ones that are based on calculations. Okay. There are more self sustainable, but tables require a lot of maintenance from our site.
Me: Yeah. And when you say replacing with Palm, do you mean that cash? But the cash forecast or you mean the actual, like, ask. Okay. As input as an assumption or some sort of input into the official planning process you would like to use.
Them: The whole thing in Palm, in my view. I mean, it depends how you want to be, how you want to build that product. But my ideal scenario would be I give you the planned figures for P and L and balance sheet. And you tell me how the cash flow will look like. And instead of me telling us the assumptions, you're able to calculate based on the history that you have from us plus the new figures. You say, hey, this is how your cash is going to look like. And whatever we calculate is always going to be based on historical data which Palm already has.
Me: Yes.
Them: And is leveraging. So, you know, I really want to, wanted to show you something later. I want to create this like high value low touch. I call it treasury. So wherever we are not needed to touch anything and we can rely on a product. Done, you know, we don't inter. Action related to the calculation. So you said that you currently do the either have these rules as a calculation or a staples that you need to be updating. How do you currently see the calculations? Is it like. How it looks like? Trying to see if I can open it. Give me a second. Is it like a chart on itself? Is it like a prompt or notification? Like, what are you used to? So I can see a little bit what you expect from the interaction of the product. So, I mean, I can show you what we do have in an up plan, but it's not exactly what I would love to replicate because this is for me very high touch. So this is how it looks like. And I haven't looked at this in a long time, but let me check on cash flow planning. I still have to take this room, Amanda, as you can see. But. So let's have a look. So you see, based on the financial statements planning, so based on the balance sheet and the profit and loss, we come up with the direct and indirect cash flow. So let's look at the direct group currency. So this is how it looks like. This is the outcome. Yeah. So starting balance, you recognize the categories from what we have in Palm. Right. But, and yes, we can see the, the values. We could see a graph, but behind this we have, let me see. I would love to see the tables that we maintain. Yeah. So these are topics we maintain, for example. In the assumptions. For example. So we have to say, hey, which way these rules we have, which, I mean, this is, I think, something that we could get from the internet, to be honest. But anyway, so we went to the VAT assumptions. We can also exactly, if I'm not mistaken. These are the calculations. Exactly. So I can always maintain this if I think, hey, for this company, I actually think we are paid faster. Than the Gracle because we've changed the payment terms. Then I could change this here. Right. So I can change the split to see the speed at which is paid. Yeah.
Me: Sorry. That means, like, you'll get paid within one month in 70% of the case and for.
Them: Exactly. Exactly. Also here, I think these are the days that I know the months that I assume. Yeah. So it's, for example, the inventory logics are very complex. So to how to get from inventory to. To cash the cost of goods sold, it's super complex logic. And I always wonder, like, wouldn't, I don't know. Wouldn't it be easier to try to get that number from inferring, like the relationship between different kpis we already plan instead of this very complex logics, you know, like there has to be a correlation between at least two kpis here. Like, I think we just took, it's very, it's very sophisticated. But I think sophisticated is not necessarily something good here. Because it's just so 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.
Me: Understand. So for inventory, I guess, I mean, do you think there's anything Palm can do to a proxy diet like the cogs? And I don't know. I'm not actually. I don't know what.
Them: No, the thing is.
Me: Yeah.
Them: We don't really want to. So inventory. I think this is just a detour to get to the, the money that we pay every month to the warehouses. Right. So they plan in cost of goods sold, so they, they plan what are going to be the sales per month, and then you have to recognize the cost of those goods as COGS that month. But that's not what you pay because you pay in for the inventory that you already bought. So that's how, why they do this detour. They say from the cogs, I want to get to inventory and for inventory. Then I can see the movements in the inventory is what I should have paid plus the payment time. So it's so complex. I think if I just tell you how much we're going to sell, or maybe we can do that based on the past. You see, in the past, we pay, I don't know, 200 million per month. And you see that we're going to grow our sales by 10 and then you say, okay, this plus 10 should be more or less what you pay. And maybe we land at a better figure. I don't know. I think this is where statistics do a much better job. Than we can do. But, hey, if we reach the conclusion, it's impossible to get this number right. We really need a more complex logic. Then we can see where to maintain these assumptions. Right. But I would love to challenge this. This is very complex for me. One question. I love the, the term low touch treasury. Do you have a good example of this? Even if it's not necessarily on the platform or the UI, but like top of mind, because you just mentioned, let's not replicate this, what would that example of low touch pressure looks for you today? This is what I prepared for offsite in a few weeks showing you a sneak peek. So this is our tech ecosystem. You'll see Pal there. So this is what we use, right? This is our ecosystem. And right now we kind of have to log in into all of the platforms to do our operations. And my vision is that in the future, if this Infinity Loop, as I call it, the treasure infinite data loop is really flowing and the data is, you know, going through all of the platforms and feeding every system, then we would only have to log in into these three systems. And my idea of low touch is that we really minimize the amount of clicks that we need to do in each platform. So first of all, we don't have to log in into the rest. And also we really have a very clear idea of the activities that we do in each system. So I have still haven't finished this. But the idea would be that we use only these three tools. So Palm is where we do our cash forecasting, where we do treasury operations. And looker is where we report. And all of the data is flowing through the systems via the data lake so that the report is always automated. So it also means the data from Palm. I mean, Palm is going to feed from the data lake and it's going to take the accounts receivable, accounts payable, the statements we already sent, it's going to take the long term plan if we work on this and then it's going to feed the information back. So Palm is where we create the forecast. My idea is that we only log into Palm to confirm that the performance of the model is going great. Honestly, we shouldn't click anywhere there. It should be more like, oh, yeah, everything looks good. Otherwise we get an alert. We do the categorization there. So I see some work there, right, to make sure that it's fed with the right, like prompts. And then that data flows back into the data lake and we can report on that plan. We can use it in k controlling can access the data lake if they want to see the plan. That would be my idea. Love the happy path. So this is like an everything is going as we expected in case something like Palm suggests to you like, hey, there's a risk state. There is a deviation that you might want to look into. Would you expect to act within Palm or you would be acting outside of these tools that should be reflected from your data sets later? I think we need to act anist in kla because that's where we can do operation. So that's where we can send payments. And the point is where we will see that notification. So I, my expectation is that everyone in treasury logs into Pan franc in the morning. And then this is where we would see those alerts of like, hey, you have an account that is going to be undercovered or you have an FX like you plan to have USD and suddenly you're going to be short, especially when we have more complex FX trades and so on. So I would expect those alerts to come in Palm. The data is already in k by the time we lock there. So it's flown. And then from k, we can say, okay, now we know this. These are the transfers that I'm going to plan or these are the FX deals that I have to make. From k. Let me go one slide back. So from the information goes to fx all to the banks, the payments. The operations happen there. And then that information can even flow back to Palm. So that Palm said, okay, good. I see that you executed the payment alert closed. Okay, so it's like more of like making sure that things are going according to plan or the decisions that I've made, but not necessarily to fix it or alter it within Palm yet, let's say. I mean, the thing is, let's see in the future how the product evolves. If we could click and generate the payment that flows to k. But I think this is a bit more complex because it involves like payment formatting and stuff like this, which I know Palm doesn't have in the roadmap yet, say no. Okay.
Me: Not in the near term, but it's definitely not ruled out. It's.
Them: Yeah. Fair. But I think that's a completely different Beast. The payment. Yeah.
Me: The FX parts are very interesting and something that we are Keen to look into next. So I'm sure that the team will reach out to you for. For more, like, information on your.
Them: Yes. Yeah. I think exactly when we spoke about it, we've spoken a bit more internally, I think for cash flow effects monitoring and hedging. It's really helpful because Palm already has all of the data. And has the projection. So you can tell us where we're short for the balance sheets. We spoke about it. Like you would need much more data from Dynamics. So I don't know. Let's see. But for the cash flow, I, I expect Palm to let us know, like, hey, you have a trade coming up in three weeks and you're super short in cash because the cash is sitting in China. So you might want to ask the Chinese team to send that cash to you. This is where I see Palm as super, super key.
Me: Makes a lot of sense.
Them: And this is low touch. Right. So Palm is replacing the treacherous logic. Because instead of us coming to that conclusion by checking, oh, we're short, oh, the crisis in China. Oh, we need a repatriation action. Palm is just telling us. And we're, like, directly calling the Chinese team.
Me: Yeah. I love that vision. All right. Just thinking a bit, if we are going to back, back to the direct and indirect chat. I could also quickly show you the prototype. But remember, it's a prototype. It's not like we will build exactly this. It's just. So far me exploring a direction. It's coming a lot from. We see a need. Most of our customers do have a need to kind of. Compare the two, the direct and indirect budget. S. And then explain why they deviate from each other. If that makes sense. But I also picked up on your point on extrapolating into the future. And I think let's. Let's just look at it. This is a very naive version, right? So if we start looking here. Graciela will be able to make this much better design wise, hopefully. But the idea is to have, like, your whatever you call it, your fpn budget or your indirect, whatever you want to upload. Plotted out next to your actual historical actuals and the Palm forecast. So you would be able to, at a high level already there, see how, how, like, aligned are they?
Them: Of the fpna budget here. Would it be p l?
Me: Yeah, it could be. Yeah. Like, whatever makes sense to you. Right? The thing that we're thinking about is. Probably what we need to support is you would have likely a bit more high level buckets, if you will, on those forecasts. You have your more granular transactional data in Palm. Right? There's likely going to be some categories where Palm is kind of fail, like, in terms of your budget. We might not be able to just derive that. As of today, from the transactional data. But what we're thinking about as a first version is essentially anywhere where it makes sense. Like customer collections, for example. As a high level budget item. We could just make sure that it maps to the relevant Palm categories, right? So you, maybe you have three, four different types of collections. So you just roll those up into that bucket. And then suddenly you get a little bit more granularity and possible explanations by entity, by whatever, right? That what is driving the difference between your plan and your reality. So that is our current focus to be blunt, like trying to map them together. And then help you see, hey, what are some notable variances between budgets, for example? Let's say my customer collections are way below plan, let's say, for this company. Why. And then we will try to have like an intelligent. Explanation as to why. What are you thinking? So again, this is not like, oh, we're building exactly this. But.
Them: Think? I'm just trying to think. I think we might be a good pilot customer because we could give you. So because we already planning on a plan, we do the translation of the budget to direct cash flow. We could upload it and we follow the same categories across platform. So we have the same categories as in pound. So this would be a very, it should be a very easy case for the tool to do the comparison. And then what's interesting is to test the boundaries of the tool and say, okay, what if instead of giving you the direct, I give you the indirect? With the same categories, but still indirect? And what if I go one step further and I give you just the p l, how good is it? No. So we can test where the, where the tool finds its limits and why, you know, like what, what kind of additional mapping or prompting or instructions as it needs, because this is very interesting.
Me: Yeah. Right. Like maybe data gaps could be a thing as well, but yeah.
Them: Yeah. Yeah.
Me: So yes, basically what we're trying like to just show this is just mock data, but we're trying, I'm imagining maybe some sort of signal in terms of understanding. Why is it deviating. So you could see like, well, your collection is lagging compared to Plann, for example. Stuff like that would be interesting to, to understand. That's kind of. Where we're at right now. And then if you want to drill down further, we have this maybe, maybe, maybe you keep going in post. Maybe we open polls up here on this page with all the context, you know, so like there are, there are, we are like thinking actively about those bits as well.
Them: What's the customer, the target customer here? What profile do you expect to use. This?
Me: Sorry again what profile.
Them: What are the customer, the type of. User that you expect to use this function? Is it the treasury team or rather management?
Me: I mean, for depending who wants to do the analysis, like in this sense, it's more the treasurer. I guess. But super in super interested in hearing your point of view.
Them: Yeah, I'm trying to, I mean, I would be super interested. I don't. I think it depends. A lot of treasury teams are like, hey, I take care of my direct cash flow. P l is controlling. I would love to go there and be able to go to controlling and say, hey, I can tell you from European air, I can tell you how that's translating into cash. And then I can explain much better how the cache is developing and how that bridge. So for me, it's super interesting. But I also see a potential usage for a CFO or for someone high in controlling to understand.
Me: Yeah.
Them: So I think you open up the tool to a different profile.
Me: Sure. 100. I, I want to hear more. I just wanted to ask because we were thinking, like, let's say some of our customers do have a bit of, like, trouble with some of the entities, for example. So if you could upload some entities do their own PLS or whatever. Right. But they are continuously off.
Them: Yeah.
Me: And this could be a tool that helps, like, collaborate and talk about, well, the reality is repeatedly counteract what your budgets keep telling us to have, like this as a surface between, like HQ or global and, like, different entities as well. Is that something that would be relevant? To you? Yeah. Yeah.
Them: What we, what I think we. So the controlling team is checking PL actual versus forecast with the regions. Right. So we have, for example, the APEC region is always off because we grow faster than they expected. So it's a nice problem to have. But still, the forum is always. Yeah. So I know the controlling team is then challenging them, but they use ana plan for this. So let's say the actual versus forecast when it comes only to PNL or budget, as you call it here, that happened in a plan. I think what's interesting here is for us to be able to go to the as a treasury team, to the regional team and say, hey, your forecast is off. Cash forecast. And we believe it's because your underlying PL forecast. It's, there's something happening here, right? Or even there is a performance topic. Like you said here, like we're, we're collecting too slow. Right. So that's what I mean, that I see this role who uses this a bit blurred because it's a conversation that's probably half treasure, half controlling. But super happy to go into this in between area. So.
Me: Yeah. No, that's super interesting. Like, I love anything that also Fosters, like, better collaboration between the different parts of finance. Right. So it's something that could help there. I think that's really interesting. Did you think, like your CFO would go in here as well, or did I hear that correctly? What would, what would be the motivation?
Them: I hope so. I would. The use case would be, hey, I want to understand how, how my PNL transforms into sales. Right. I mean, we report this back to him. But if he has time and interest, I would expect him to want to come here and say, okay, let me see for myself. Let's see the insights that I get. Because I think you also get hints on what should be changing if you want to cash in faster, then you need to pay attention here or there. I have a question. So. I, I'm still getting around of, like, the account on itself and, like, what the feature is about as, you know, I'm just onboarding. But I have a question on, like, you said that it's clear that you want to be using Palm for forecasting. And because it has this ability of, like, the categories. Let's say in these key activities that you have highlighted for forecasting would breach be one of them as something that you would already have highlighted as key activity. I'm kind of thinking of, like, I have really resonated with the low touch part, like as frictionless as possible. So if, if the assumption is, like, coming in to just see the things are going as usual, when I'm looking at to the forecast, is bridge as the second thought or is it part of, like, the key activities that they would be doing? Honestly, I think it's goes very much in line with this low touch because as a treasurer, when I log in and I see my forecast, there are two ways of telling if a forecast is good. First, it's the variance analysis. So I see that in the past it was hitting or it was coming close to the actions now. And the other one that normally we do off Palm, and it's more of a gut feeling, we call it plausibility check, but it's a, let's have an educated guess is as my forecast more or less match what controlling is saying we're going to hit. And this is what you're bringing here with data instead of a gut feeling and possibility check however you want to call it. So, yes, you're, I think you're reducing an activity that is very high touch, which is us in an excel taking there or inannu plan checking and seeing how the forecast compares to the long term plan. So if you're bringing this here, you're reducing a manual activity. And you're allowing us to do that second tick in our head of like, oh, yeah, yeah, go see line with what controlling is saying second reason to believe this is a good forecast and we can act on it because this is also a bit the, the fear. That I hear. And this is why I'm also happy to open up Palm to more integrations with the data lake. Because if you have access to our booked transactions in the ERP statements and the long-term plan, you have everything that we could have in an excel. So it's always going to be better than when we come up with in an excel. But if you don't have the long-term plan, I can always hear the argument from the rest of the team saying, but how could they predict how our growth look like? We grow like crazy. No one can predict our growth. So I think it adds.
Me: But were the expectations from the team for the long term, then we that we also somehow made use of those plans in our forecast? You know what I mean? Or.
Them: Yes. I mean, I think for the short term, it would be interesting to give it to art and see what he thinks. I think you come up with a better forecast by ignoring the long term in the short term. But the moment you go beyond the 13 weeks, probably you need that, especially if you go beyond the few, I don't know, like six, seven months. But for the short term, no, I think for the short term, it's more of this validation of like, hey, not only is Palm getting good variants, like with Wape, but also it's more or less in line with what's controlling was saying we were going to hit.
Me: Yeah, I'm thinking maybe I'm being, like, overly abstract or philosophical now, but I'm just saying, like, hey, that basically a very high quality assumption that you want to bake into your long-term forecast. People made a lot of effort, like planting this out. There's a lot of human and internal knowledge going into this. So that's, is that the kind of assumption you would like to be able to use to nudge the, the Palm forecast in more correct area?
Them: Yes. Exactly. I just think in the very short term, because it's more of an operational forecast for treasury to move cash. I don't know if controlling. Can help us there. So we need to see the reality and the reality is the actuals. But the moment that you go beyond 13 weeks, which is, it becomes more, as you said, of a philosophical conversation of where is our company going, then I would always want to take a source of Truth with controlling a sane, whether I think it's good or not. That's our source of Truth.
Me: Yes. And I think it makes sense because it is inherently harder to just do machine learning based longer term, like the, the insecure, like the, the bonds will increase. So it sounds like something that could help. Yeah. I mean.
Them: Right. Yeah. And.
Me: Yeah.
Them: It reduces the noise in the conversation when you say, like, hey, we're using machine learning, but just so you know, the longer term we go, the higher the weight of the forecast from control intakes because we just acknowledge that we can come up with a different number, but it just creates friction in the conversation with controlling when they say, yeah, but you're not taking our numbers.
Me: Of course.
Them: Right, right. Because we want to speak the same language for the long term. So in short, you said, would you expect us to use this in the forecast? Yes. In the long term and for the bridge, for sure, you need that in order to bridge something. Against that. So I think it's very valuable information that we need to be able to fit into. Palm.
Me: Yeah. 100 agree. How often do these type of forecast update?
Them: More or less every three months. We have a new forecast. Yeah. And it would be available in big query. So it's also pushed there. So we just have to build a connection.
Me: That was going to be my next question. Like, would it be anaplan or is it in. Okay. Okay.
Them: That's why my data lake is, has this middle point of the.
Me: Absolutely 100. I just wanted to make sure if, so if it was already there or part of the vision, but. Cool.
Them: No, I might deal with video connect. So I told Andrew already I want that connection to be directional from Palm to the data lake and vice versa because we also expect to fit that information from Palm. To be able to use it in k. And we're giving you access to the arap table. But I want this to be the first act table that we give you access to and then we can add more.
Me: This is very cool. Love it. So just some more, like, specifics. Do your regions have their own budgets or forecast two, or is it more at the global level?
Them: I think it's quite centralized. So they give it to the global team, so I would not expect them to have additional numbers.
Me: Okay. Good. But so if I'm hearing you correctly, you would like to use it to boat like align teams. You would like to possibly have Palm in the future be some form of input or even the source of truth for certain types of high level planning. Is it. Valuable still to get this type of insight around what could be driving the variances between the forecasts right now?
Them: Between the forecast.
Me: So let's say I have a, I have a delta between late in this case. My customer collections. Right? This is my budget, like my indirect forecast number. And this is my actuals. And then there is a variance between the two. Would you be interested in trying to understand why that is?
Them: Yes. Just trying to think. How would Palm come with what it is. It's quite a lot of analysis there.
Me: Yeah, for sure.
Them: But yes, of course, because if we go back to this low touch, if Palm is not giving us the reason, we would have to investigate it. Otherwise.
Me: Exactly. So maybe what Palm could do at least at v0 kind of thing is surface potential things that could, could have contributed to it. Maybe Pan can look at trends.
Them: Would we be able to give feedback here and say, yep, that's the one we checked and this is the reason and then give feedback to the tool. Would it help?
Me: Maybe that's an interesting thought, and I think it's a good idea also just for your sanity to remember, like, hey, maybe, you know, I recognize this, and I've already dealt with something like, you can see your old comment or your old conclusion.
Them: Yeah, exactly. Yeah. Yeah, exactly. Because. I would imagine in when we go beyond this prototype, you would also be able to filter for the past and see how. You know, that bridge looked, I don't know, six months ago and then able to see my selection and my comment of like, hey, this is what it was. I confirmed with this person.
Me: So maybe like even some way to quickly just also find whatever you input that maybe like a separate thing or. Yeah.
Them: Yep. But ideally it would be kind of fed back into, you know, so it's kind of. Helps identify this directly the next time. Right. So a bit more like the categorization. Prompting. I don't know.
Me: For sure. Yeah. Yeah. No, I totally hear you. Just. Just trying to already, like, in my head, plan this out. Like, I think, you know, typically v0 is the most naive version and. And then kind of working, I think, from there. But this is. Super valuable feedback. Thank you.
Them: I, I have a question regarding assumptions. So it's like the way that you describe it. And let me know if I misinterpret it. It's like an educated guess. Right. And each person has, like, different way of interpreting. Based on experience and the same data might look different on, like, the approach that it might have. Or that this or ability of how that number should change over time, let's say. So is that accurate? Would I capture what you were saying? Like this assumption part. I'm not sure if I could you say that again. When you were mentioning about forecasting that there was two instances, the past of the variances and the second reason was like based on experience or assumptions that one might have. Right. I'm just wondering from each user one might have a different experience, therefore different assumptions or how. Well, it should all come from the controlling assumptions, so to say. So, I mean, I can have my opinion of how I think the p l is going to look like. But in the end, I have two also accepted controlling version is the source of Truth, right? And the idea is that all of our assumptions are fed into that plan. So how controlling comes up with that number is it's also a collaborative process in the end. So I have, I'm responsible for bank fees, for example, so I need to give them my estimation of the bank fees. And they take that and they also go to the sales team and say, hey, how are the sales projections? And they take that and then they add everything up and all of that is what constitutes that budget. Right. Or that P&L planning. And then that's our source of Truth. Right? It's, I can look at the sales and say, hey, this is completely unrealistic. But hey, got sales team said that. So. Okay.
Me: Right. So. And that, just to be super concrete, like that assumption, the sales assumption would be based on, let's say, maybe historicals, and then you go, like, multiply by 15 because we're doing amazing collaboration with this big person, you know, celebrity. So we think that's going to drive a lot of stuff. So that's kind of how assumptions are created.
Them: Yeah. Yeah. Science and a lot of art in forecasting. Right. So I think some people will say multipliers and people will say, let me look at the sign contracts and send them up. It depends. But anyways, they consolidate this. They, they sense check that they make sure that this makes sense to them. And then that's the source of truth. So I think there is once it comes into Palm, there should be no interpretation for how the forecast. That's the forecast. And it's too much what we see in anal plan. Right. Okay. Where we would have different potential resources on that bridge and even there, I mean. If we have all the time in the world, we should be able to investigate which exact reason it was. It can be a combination of things. So it can't be a combination of three big customers paying late plus, I don't know, it's something in the bank happened in the bank. And it can be a number of things. But if I can tick them off and or take the biggest one, then maybe it helps the tool be a bit more precise about the guess of what it was in the future.
Me: Yeah.
Them: I was just thinking, like, is this being fed by something specific or it would be created from scratch from Pulp? But now I realize it is being fed specific.
Me: But I, I still think, yeah, I think it's good for, for you Graciela. Like, also, I think, like what you said before, Lucia, like, broadcasting is a little bit of an art, too. And even the scenarios featured still, it's been parked, but we, we really get it out. That also has this notion of, like, assumptions into it. Right. It could be, or we call it assumptions at Palm, leaves, but it could be even for your short term. Right. Covid happened. You know, we're going to immediately need to assume, like, that's going to hit us somehow, even in the short term or like the next 13 weeks and maybe not something you want to bake into your short-term forecast. And, you know.
Them: Yeah, I think we, this is where I go back to the idea of low touch. So on a, on a regular day, I would love for forecast to be more science than art. Because of the assumptions that I can come up with will be a calculation that I do either in my head or on a piece of paper or an Excel. So if any tool can do it for me and I can just look at it and say, yep, sounds about right, then no touch. Yeah. But I always want to have the option to go in and say, nah, let me type in five instead of two just because something I heard or something I think or something I want to simulate. So I think this is where the low touch comes in where I have that possibility of coming up with a better assumption if I believe I have it. Otherwise business as usual, you do the calculations for me.
Me: I love that distinction. Like business as usual. I have no reason to believe something is off. Just, but maybe you would like to know if we have reason to believe something will be off then. So you'd like that feedback loop, too, I guess ultimately.
Them: I want exactly and I need visibility. So what's interesting here is in the note, in the no touch or the low touch version, I also need to see how you come to that number. Right. So the calculations, but that's why I'm, I'm giving Janice constantly this feedback of the variants tool needs to have much more information for me to be able to fully trust that your approach is a good replacement for my high touch.
Me: Yes.
Them: It is right. I know, I know it will be. But you also need to build that trust.
Me: So explainability.
Them: Yeah. Yes.
Me: Matters a lot there. Yeah. Very cool.
Them: Yeah. Yeah. I just, I was, so I'm using a lot now. Gemini within Google sheet. So I was, I was building an analysis, and this was a great example of a low touch. So I create, I created an analysis, a net present value, and I just created one scenario. But then I went like, oh, I want to have a graph with different scenarios and timing, but just doing this myself, like typing in new assumptions and writing down the results and then plotting it. So boring. So I started with gemini. I was like, hey, I want to build this graph. Can you replicate this, these scenarios for me? And then you, I could see now has this function where it tells you what it's doing. So you can see how the tool is like. So I'm now looking at these assumptions and I'm now validating this. And, hey, I've just hit this. I'm going to check if this is true. And then, and you can read. I mean, it goes so fast that you cannot read it, but you're like, oh, yeah, that sounds human. That. Yeah, yeah, I like it. So it gives you, you know, that explainability of what the tool is doing. It just gives you.
Me: 100. We should definitely surface more of that at in pole as well.
Them: Yeah. Yeah.
Me: Like align with you. It's, I think, and that's the whole thing. You don't want to, you're never going to trust a black box. No.
Them: Now because also, I mean, you're creating. It's not a chat GPT. This is a very specialized tool for people that have been doing this for years. And so we're going to have very high expectations of, no, I expect to see this graph looking like this. And I, you know, and I give you feedback and I tell you exactly why. And then, you know, I expect the challenge, but I also expect the, let me explain to you why I'm challenging you back, right? Otherwise. Yeah.
Me: 100 very valid feedback. Okay. I'm feeling quite happy. I feel like we've high level validated the direction this is going to take. I think there'll be some open items in terms of, especially the data ingestion bits. Let's see if we are able to grab it from bigquery. Easily. We could also manually just put something in our database to begin with.
Them: We could upload it money to start with. You want us to. Yeah.
Me: Just to, just to get going. But we definitely need to solve the. The management of all the bridging data somehow. Cool. Anything else?
Them: No, I feel. We, we give you a lot. Graciela, if you want any more, I don't know, documentation if it helps you, then happy to share. But I also agree with you that I don't want to bias you. And what I showed you is not what I necessarily want to see. So also nice to have a white piece of paper. And, I don't know. Come to you with your own conclusions. Yeah, for sure. I appreciate of, like, what's the baseline of what you're currently working, especially since you're thinking of migrating. So, yeah, I think this is good enough. I'll for sure reach out if I need anything else. And I can also look into post hog and jannis. So I'm not concerned. Well, thank you for having us as the, you know, guinea pigs. I love bringing it.
Me: For being one. Very cool. Okay, well, chat to you soon, I hope. And.
Them: Likewise. Bye.