Skip to content

ON - Kyriba & HighRadius Forecast Walkthrough - 2025-11-17

Metadata

  • Date: 2025-11-17
  • Company: ON
  • External Participants: Yulia Ershova (Treasury Corps - Cash & FX), Rodrigo Cabrera (Treasury)
  • Palm Participants: Emma, Rodel
  • Type: Customer Call
  • Domain Areas: Cash Forecasting, Cash Visibility, IC Activity, Variance Analysis, Forecast Performance
  • Recording: https://tldv.io/app/meetings/691b388b82e614001374b22a

Summary

Context

Deep-dive working session with ON's treasury team to understand how they currently use Kyriba for cash forecasting and HighRadius for collections/AR management. Purpose was to learn their workflows, pain points, and gaps to inform Palm's product development.

Key Discussion Points

  • Kyriba forecast is straightforward: open AR + open AP + manual forecasts (salaries, taxes, significant payments)
  • No ML or AI in Kyriba forecasting - just open items and manual inputs
  • Cash pools create visual clutter - pooled accounts show negative balances that aren't real overdrafts
  • HighRadius handles collections/AR with customer payment pattern recognition
  • Open AR/AP data from Dynamics has timing issues when payments aren't settled same-day
  • Variance analysis is currently mental/manual - no systematic process in Kyriba

Pain Points

  • Cash pool accounts show misleading negative balances - "Seeing this minus is not really helpful" for pooled accounts
  • No smart forecasting in Kyriba - just open items, no ML/patterns
  • No category-level views - can't see development of salaries, Capex separately in Kyriba like they can in Palm
  • Dynamics data timing issues - paid items still show as open until accounting closes them
  • No variance analysis capability - "Variance is not there. No comparison."
  • Outliers skew forecasts - large one-off payments distort future predictions
  • Collections forecast inaccuracy - AR team knows customer patterns but data doesn't flow to forecasting

Feature Requests & Needs

  • Group/filter cash pool accounts so negative balances don't clutter the view
  • Show cash pool sweeps as flows from master account, not individual participant accounts
  • Category-level forecast views (salaries, Capex, etc.) - "what I really like in Palm from visuality"
  • Apply historical payment patterns to AR (e.g., only 80% of expected inflows actually arrive)
  • Ability to mark transactions as outliers to exclude from forecast learning
  • Anomaly detection - flag unusual transactions automatically
  • Weekly variance analysis aggregation (daily may be too noisy)

Jobs & Desired Outcomes

Job: Determine daily/weekly funding needs across cash pool Desired Outcomes: - Minimize time spent identifying which pooled accounts need funding - Reduce false alarms from negative balances on pooled accounts - Increase accuracy of cash position view by showing sweeps correctly

Job: Improve forecast accuracy by handling outliers Desired Outcomes: - Minimize the impact of one-off large payments on future forecasts - Reduce manual effort to identify and flag unusual transactions - Increase confidence in forecasts by excluding known anomalies

Job: Understand and explain forecast reliability Desired Outcomes: - Minimize effort to identify when forecasts are significantly off - Reduce surprise variances through proactive anomaly alerts - Increase ability to investigate root causes of forecast misses

Domain Insights

  • Kyriba architecture: Initial balance + expected outflows + expected inflows = forecast. "Nothing super smart, nothing of AI"
  • Payment runs: Different entities have different payment run days (e.g., every Monday for one AG)
  • Cash pools: Master account (on AG) funds participant accounts; sweeps are automatic but forecast doesn't reflect this
  • Buffer logic: If payment not made in last week, assumed to go in next payment run
  • AR collection patterns: HighRadius knows customer behaviors (e.g., "Foot Locker always pays on the 20th") but this doesn't flow to cash forecasting
  • Terminology: "Cash application" = matching incoming payments to invoices in HighRadius

Action Items

  • [ ] ON to share example of outlier transaction (11M) for Palm to test exclusion
  • [ ] ON to ask HighRadius team about promise-to-pay data availability
  • [ ] Palm to explore anomaly detection for unusual transactions
  • [ ] Palm to consider outlier flagging in verify flow or transactions table

Notable Quotes

"What Kyriba does is grabbing our initial balance, adding all of the expected outflows, expected inflows. Nothing super smart, nothing of AI, no nothing fancy." - Yulia

"If you see OK, we have expected inflows of 300k, 500k every day. But usually you only get paid 80% of that - maybe show only 80% as a more accurate cash in." - Yulia

"If there is a one off payment which is sometimes couple of millions... to untick it from the learning... because we checked them, they are really one off and they will just skew the whole future forecast." - Yulia

"Variance is not there. No comparison. This is what we are not doing either." - Yulia (on Kyriba's capabilities)

Full Transcript

Me: Hey.
Them: Hi.
Me: I'm all right, thank you. How are you?
Them: Watch me. Well. I had a wonderful son today for half an hour. It was truly energizing. Until it is back to rain.
Me: I feel ya. Hey. I'm gonna start screen recording now at your zero way. Yeah, I feel you. There's a lovely time of year.
Them: Exactly. I just need to hold on until the Christmas beauty start.
Me: Yes.
Them: I rodel? Yeah.
Me: Hello. Thank you for making the time, Julia. I know you're probably pretty busy.
Them: That's good. That's good. No, I mean, it's nice that we have the session, so I think it's beneficial for all.
Me: That's the hope, isn't it?
Them: The teeth. Rodrigo joins. Me.
Me: Hey, Rodrigo.
Them: Hey, how's it going?
Me: How are you?
Them: No good. All good, thanks.
Me: Nice to hear. So I think what me and Rodel hope to get out of this is actually. Just if one of you would like to screen share, we could start with Kariba, maybe. And just help us understand how do you currently use it to produce or use your cash cost? S. And just like voiceover, your thoughts, opinions. What you like dislike just so we don't accidentally do anything in palm. And how can we build something in terms of the user experience but also like the outcome of the forecast? About how easy are they to work with. But is there anything where Cariba currently falls short? That you think? We should spend some or direct their attention. That would be super interesting.
Them: Yeah. Let me share my screen. So what we have in Kriva is pretty straightforward. It's open ar. Open ap. Daily transactions that we have done through Kiriva and manual forecasts that we have added through kiriba. Those manual forecasts are salary payments. So we have a recurring salary payment on monthly basis or any other expense or outflow the regions consider a significant amount. And that they input in the forecast, either themselves or we input it for them. Or, for example, if we hear there's a huge tax payment, we also input it there just to have a clear understanding on how we are going to end the day, the month, a week, whatever. But for the most part, it's open AR and open ap. And that's, of course, the data that we have shared that it's coming from the hex, but other than that, it's super straightforward, super simple. What Grima does is grabbing our initial balance. So the balance of today. Adding all of the expected outflows. Expected inflows. And then we receive a forecast at the end of every day and depends on how we are looking at it. It's on a daily basis. Then it moves to a weekly monthly basis. The farther it goes in the 13 weeks. But, yeah, it's basically that is nothing. Super smart. Nothing of A.I. no, nothing fancy. We have the initial balance. We can see all of the outflows that we might have. We can drill down into what those outflows are or inflows. We can also go a step further, like whatever it outflows and inflows.
Me: How useful is this for you guys now, considering it's just OpenAP and AR? Like, what do you use for.
Them: It is true. It's the only thing that we have, and it's accurate as we can get, so we use it. Every time that we need to take a decision on either investments or trading, like for example here. I know on the 24th of November I'm going to be an overdraft for CHF, so I need to plan ahead a few days before to buy chf. Why are we going on overdraft? Because we have a cash out of salaries. So I know we have an 11 million outflow of cash outs on the 25th of November. So these are the manual forecast that we have input, but also we have some cash outs based on open invoices from the team. So we know we are paying all of them.
Me: Oh, when you say, just curious, like when you say, you know, you're paying all of them, is that typically how it goes? Do you typically follow the specified validate or the planned or the scheduled payment? Date.
Them: Yeah, we are usually not. Past due on payments. Right, because other ways we get. Binds penalties or we may get stopped a service. So we are usually on time, but we also have a buffer. So if it hasn't been paid in the last week, we put it on the next payment run. So for example, if we have item passed due in the last week, we know every Monday there is a payment run from one AG so the value date changes. To the following Monday. So if the invoice is not closed in our erp, it will show us pending to be paid on the following payment run. So it depends on the entity the payment rod is on different dates. Yeah. We have assigned different bank accounts to different flow codes and budget codes. So we know that all of the cash outs are coming from this account. That is the payables account. From one, all of the inflows are on another account. So it also help us visualize it as an account level. At the currency level, all depending on how we want to look at it. We can have entity level view, so we have that flexibility on how we want to look at things.
Me: Yeah, yeah. And I know this is something. This would be helpful in palm as well.
Them: Yeah.
Me: So you could. Is it? Is it? Mainly so we've understood entity 100%. Message received. Also currency. Anything else. Yeah.
Them: One of the downsides of this one, for example, is you see a lot of them in red, like on Sweden, Netherlands, I don't know, Belgium, Austria. But if you take a look at them, these are all cash pool accounts and our cash flow accounts that we are not receiving any inflows, we are only receiving outflows. They are paying and they will be negative, but they will be paid through the cash flow. So the account will never be on overdraft, but we will not separate that or have a filter just for that. In one of the downsides, if we are looking at an entity level, if we don't know why or what are all of these entities, you might get a big surprise.
Me: Oh, yeah.
Them: But yeah. I agree, Rodrigo said with this one, to be honest, this is like. Emma, what you asked, what we don't like. This is exactly this part. So in case, for instance, if there is a possibility to group accounts, meaning, let's say when I set up an account and I say, ok, this account is part of the cash pool. So technically in the forecast, I shouldn't be bothered by this minus. Of course, it's good to know that, for instance, there is a cash outflow, so because it belongs to this entity, and so on, so it shouldn't be neglected. But seeing this minus, yeah. It's not really helpful because by knowing them, that's perfect. But then, for instance, let's say, or any person who is not doing on a day to day basis, there is no indication is it really overdraft? It is not. And so on. So this is a little bit.
Me: So, basically, if it's a pooled account, maybe the balance isn't important to surface here.
Them: Yeah, I mean, exactly. So the cash outs is important to know still. So, for instance, this is also what Cariba doesn't have. Let's say parentity. When I open it, I would like to see what is the development of salaries, what is the development of Capex or anything else, because with graphene palm. What I'm checking is I can see straight away. Suddenly, no salaries. And it's just visual. So I don't need really to go number by what number? Like in these columns. And see, is there zero or there is a number. So this is something that I really like in Polym from visuality.
Me: Now, I understand that looking at this. So. But yeah, no, definitely. And for pools, like, still forecasting the activity within the accounts in the pools in terms of the, let's say, individual categories, such as payroll, that's still. We're gonna keep. But here you're loud and clear. It's not really relevant to look at it from this. Level in terms of the actual balances and how that clutter your view.
Them: And I think here, of course, we focus a lot on the payouts because that's what we can control. And we have to, based on ourselves on that. So here, for example, for cash ins, if we have not received a cash in on the date that we should have, we have a buffer of a week that we still consider it as of today. If it's not tailed, then we remove it from the forecast. But I think it could be nice. Also from Pam, I know you guys don't go by customer level or by description level, but if you see OK, we have expected inflows of 300k, 500k every day. But usually you only pay get paid. 80% of that maybe seemed only 80% as a more accurate cash in could be nice.
Me: So even if it's at that level, just. That would be helpful already if we could see even at a consolidated level across each account, regardless of like, I'm just thinking step by step now, but even if we could say for the full account or full. The full entity.
Them: Yes, I think so, of course. I think it will take a couple of months to actually learn from the fact patterns of the cash in once you have the invoices of the day. But I think that will be good.
Me: For sure.
Them: But I think the pattern should be on the entity level. Right? So, I mean, we cannot really derive a pattern from a group of entities. That would be potentially a bit biased. You can do it from bank account level. So, yeah, NTT entity incurrency.
Me: Yeah. Rodel, do you have any thoughts? But I'm thinking also, if we can do it by bank account level, we can roll it up into, you know, if you want to look at it by the entity or group or by currency or. Yeah.
Them: Yeah, I think from my perspective, Rolling it up. On a different aggregation level, whether that's the cash pool or the entity. That shouldn't be that difficult, even if it's currency or country. Bank. I think we should be able to facilitate it in one way or the other. I think it's good for us to know which to focus on mostly. What I'm hearing also is like, entity, indeed, cash pools. And then I think one level deeper is going to be indeed. What buttons are most interesting to see. That's also what I'm hearing here with the 80%. I'm very curious to hear more. Maybe one more on the cash pool. Another? I didn't check with Kiriba. How it does the forecast for on ag, for instance, like on IG is our mastery account for the cash pools. So whenever we have a forecast, let's say German branch has a cash outflow of I don't know. 1 million then in the forecast, I don't know if Kiriba shows the same 1 million as a cash outlaw that day, because technically it doesn't. Right. So it shows only on the Germany. So basically that might be another case. If there is such a classification, what is part of the cash pool, then the forecast will show me zero at Germany. But then this one minus 1 million outflow on AG, for instance. So let's say Germany, Spain, million. However, I don't care about the finance Germany because I know it is financed internally with the cash pool. But what I care if on IG indeed has actually 1 million to pay for these costs. Sorry for these payments. And that would be a good option. So for instance, I don't know if in the forecast it can be done that way. So if an account is, let's say, ticked as a participant of the cash pool, then account forecast will be showing minus 1 million plus 1 million. Because the system by straight away will say that OK, I know that by the end of the day, 1 million will be. Will come technically from the master. And then this cash outflow at the master account, it will be kind of added in shows like, ok, the master account, by the end of the day, please expect that there is a 1 million outflow.
Me: And this is interesting because now we're going into, like, operational versus intercompany. Could I just, like, sanity check something? Is it correct, then, that let's say for the. It's an operational German account. I guess. It has a one out, which is an opex. Some sort of cost.
Them: Correct.
Me: Rent.
Them: Anything, any cost here.
Me: So what that would then need to result in is a forecast for an intercompany flow. Essentially, or, like, within the pool. Like, you could call it like a pool or whatever. Right. But just conceptually.
Them: For example, this one. If you are looking at any of these red marks or outdoors in Spain, these 219. Ideally it will not show us -219 in Spain. It will show -219 in on ag as an outflow. Yeah, it can be four intercompany, but it can just be as an outflow. For a vendor.
Me: Sure? Yeah, but I'm curious to understand. Like that outflow that needs to go from the parent or header account to fund the German account? To bring the balance to zero. That would be like a sweep.
Them: Correct.
Me: Right.
Them: That's pure intercompany, correct? Yes.
Me: You just need to sweep, and then I assume. Like it's nice to also some way then if you want to investigate or drill down. What was the reason behind the sweep? You would end up in that child account. And you could see clearly from that day what was the driver is that's correct. Yeah.
Them: That could be. Could be good. I would say the main for what would be clear for me to differentiate if this is a payment, which we did, let's say, instructed an invoice payment of intercompany payment, or if it is an automatic cash pooling, because then I know that if we let the whole scope of payments from ONAG to Germany. Which of them are just coverage for those expenses paid part of the cash pool, or which are the ones which we are settling the liabilities between the entities?
Me: Okay? Yes.
Them: But I guess this couldn't be done. Or I think we also kind of have it as part of different categories for payments.
Me: I was thinking I would love to learn a little bit more about what that process looks like for you and when those liabilities are settled and, like, do you keep track of balances across the pool at all? And how and when does it, you know? Yeah.
Them: Of course we have the house. Bank, please, Rodrigo. Actually, it's. It's your topic, no? And always the descriptions will be different. So you will be quite easy to identify. When are we paying interest for loans and interest for the balance or product invoices? Or whenever there is an automatic cash pool or touch sweep from manager to on Spain or the other way around, so it's easy to identify. The cash flips also are more recurrent, usually in some entities, even on a daily basis. The interest or the invoices maybe are once a month, once a quarter. So it's pretty easy to identify which is which, and also the values are way different. Too.
Me: Nice. So how does. In in terms of cash pools or any intercompany activity. How does Curriba currently support you there?
Them: We cannot see because as I mentioned, this is basically open ar, open ap and any manual forecast.
Me: You cannot see any.
Them: Yeah. You cannot see any forecasts from. A smart way or, I don't know, machine learning or any statistical model. There's no forecast. Going on there is basically our open items. And what we had to do. Also we actually named the accounts in Kiriba. Specifying this is the account master Cash Pull Master. This is the count participant so that visually when you open, you can see it, but there is no such category. Like that. It is part of cash pool and where does the cash ends and so on.
Me: I understand. Is it? Do you know if it's something they offer and that you just haven't started using, or is it just like, not.
Them: I don't think it's offered, actually. Neither in SAP nor in Kiriba. Such functions.
Me: Okay? But the smartness then I. I've read like on their website, you know, they do, and now I'm just like going there. But they do promote some machine learning capacity on their website. Is that something you've spoken to them about?
Them: They just started. I would say with this. So even. No. Yeah, they started and it's not on cash and management forecasting. It's on the liquidity planning forecast or module that that something else. Not. Not this one. Neither are our consultants from Deloitte are familiar with that, so they say it's very fresh. We just get in there. But nothing, Nothing to share or train us.
Me: Gotcha. Gotcha. Okay, so let's say in palm, we'd. We'd set up the cash pools properly. Based on what we know and also based on your feedback here, let's say it's easier to view in app this, you know, entity level forecast. You can slice and dice it. You can choose to look at it by currency or maybe even category or opex versus at some point a clean view, even maybe in the company. It starts. It. Now I'm just very like blumpier. But like what? What does it take for you to really feel? Hey now forecasting in palm will feel very. Solid.
Them: I think there is one more disadvantage for Cariba which we have is the first day or let's say today. Why? It is why? There's a problem with currency tap. So where you save receive, let's say open AP from our dynamics. So let's say if pay run yesterday. It is bank statement of yesterday. And in dynamics, the accounting team, or the process, whatever it is, hasn't closed those open items yet. Then we will see them as cash outgoing amount for today again. Which means there is no. The system cannot. Let's say match. Ok. It was planned for yesterday. Now I see. Because bank statements are already in Quiba, but there is no connection. Which means that we will see it today. Like, hopefully, the accounting will close those paid items and then we'll remove it from open positions. Then we'll have the correct view when it happens and if it happens within one day or two days or three days. I don't know. And it's kind of dependent on that. So this is another kind of weak point in cad, but that we cannot rely on today. We can see what is the worst case scenario. Absolutely. Assuming that everything, let's say, will be doubled or just still considered open, but it's not one. Hundred percent correct.
Me: And just so I understand, like, when they do report it as close. That's just a matter of like, saying, hey, we did in fact pay when we were supposed to. Or can it also be the case, I guess, when there is a delay.
Them: It could be delay, of course. The thing is. I don't know exactly how it is in dynamics. Usually if position, let's say and at which point the open items are shown. However, if open item is there and approved, technically the automatic pay run should pick it up. However, if that pay run, let's say, fails for whatever reasons, because pay run is usually a batch of payments. So within this batch, if there is, let's say, one whatever weird payment, wrong details or something, it's canceled. The whole batch will be canceled. So it can happen, but I think it's rare.
Me: Gotcha. Yeah, I think that's something we would probably like to visit again once we have your AP and AR data and just to figure out to get it how to make it make sense in palm as well. Yeah. Cool.
Them: Maybe a thought from my side is. It's also a bit of an open question. What I'm wondering here is how much of the information is already in the Dynamics data set. Versus how much needs to be kind of inferred. What I mean with that is that I get some information might not be available in the Dynamics data set, and then you need to kind of figure out if that's not, let's say, if there's no information on the payment batch when it happens. You kind of need to kind of infer that from our side. Somehow or if there are certain patterns maybe that are all the time kind of the same program. Giving a bit more into the high radius case here. We also probably would want to be a bit smarter with that, I guess. For the most part, I think we need to assume that whatever you are seeing in the open ar, open AP data, it's accurate. So whenever there's an issue or communication error between, I don't know, coupine dynamics that the payments don't get settled on the same day, Then yes, it's going to be an issue and we will see an open payment when we shouldn't. But it's not every day and it's not a thing that we need to accept. Right. So if it's an issue, it's an issue on our side or it side that we need to fix internally. But we cannot consider that any point that there are invoices that are closed but are still reflected as open. If it's open, we need to assume it's open unless we know an issue it's coming or. Yeah, well, I think that definitely makes sense. I guess the point where I'm thinking towards is indeed more already around forecasting. So given that you have your dynamics data, How would you kind of use that to construct, I guess, the actual forecast that you see in palm? And the easiest way is just to use the numbers that come from dynamics, of course. But the next step might be is use those numbers and then try to see whether the patterns from that and then infer those into a forecast. Yes, it makes a lot of sense. Yeah. I think that the end goal of adding all of this data. I saw further enhance forecast. Right. It's not to substitute, it is to make it more accurate.
Me: Sounds very good. But that being said, I think both me and Rodel are quite curious. How high radius. Sort of enhances the AR data today. I remember you mentioned a bit, Rodrigo, in the workshop that we did in Berlin.
Them: High radius is basically order to cash management tool. So customer management tool where they are managing collections, credit and cash application. So they are handling everything. Customer related from there, and it's just a more accurate way of or the smarter or automated way to handle customer customers. So there's a direct integration between High Radius and Dynamics. And as soon as we receive a bank statement on a daily basis, High Radius is settling the invoices that are paid. And automatically sending a notification to Dynamics. But yeah, that at the end is going to be reflected on the open ar, open ap. So yeah.
Me: Would it be possible to take a look at it? Like we heard, for example, they do set up customer profiles in high radios as the foundation, we're just super interested to understand, like how it actually works and how do they arrive at. You know? If we understand correctly, because they do in fact, in some manner or capacity, model out sort of behaviors across customers in terms of when they pay or.
Them: Let's see. Yeah, they do. They have some customer patterns and everything, but that's under. It's not something that is reflected on the user screen, it's more on the back end. And it's more on recommendations to the customer. So if we have, I don't know, Food Locker as a customer, And based on historical patterns. High Radius understands that they pay on the 20th of each month. They will prioritize emailing Food Locker for a collection for collections or sending invoices closer to the 20th. And that's handled by the AR team. And then at the same time, they are understanding not only the patterns. Of the cadence of the payment. But also put locker always has this in their description. And they know how to allocate the payment. But I don't know if that's something that can we can use in palm. Maybe if we go a step forward further, and we want to forecast customer payments in palm. Then yes, it may be helpful. But from what I understand, you don't want to go to that customer detail level of forecasting things.
Me: I mean, we're still exploring. It would be super interesting, if possible, to just learn how they are doing it. But if. You are able to log into high radius and just show us. That would be really interesting. We do. We do get. We do here use cases that is around like collections as a category and that is notoriously hard to forecast. In a cache. Cache forecast. So we're very open to understanding and exploring any ways in which we might. Eventually place where we can help. Make those forecasts more accurate as well, right?
Them: Yes. Let me see. My single sign on is not working.
Me: And also just curious like if are you thinking for the AR in palm? Let's say that we pull into our forecast. Will that be just the open AR, or will it be high radius enhanced data?
Them: I think, for time being, It can be only open ars because. There is no connection for all of the enhanced data or insights from high radius flowing to Dynamics or to the data lake. It stays within high radius. And I don't think we want to prioritize connecting palm through high radius now. Right.
Me: Just curious, like, how you. Because I would imagine that that should drive accuracy a little bit in terms of cache.
Them: Yes.
Me: Count, like the most likely time when you'll actually receive the funds or the payment, right?
Them: Let's see. Let me see. Let me log in. Let me see. Because, for instance, I don't. I don't have access to High Radius. So this is something that I'm not, not using. Yeah. I think ultimately, of course, the more precise the part of the forecast are, the better. I think costs are always a priority. Or let's say the expenses are always a priority. So the rest is good to have. But yeah, Ezrigo said. Should be step by step.
Me: Makes perfect sense.
Them: Yeah. So this is how. I really looks like, honestly. Lately. I've only worked on the cash application module, so I'm not sure how it looks for the collections or more analytics side. But here we receive a statements on a daily basis. And then High Radius is reading or going through all each of the payment lines that we have received and allocating automatically to a customer and invoice. If they are not able to identify any invoice, they kind of leave it as open and the team has to come here and manually assign it. From also high radius. Inputs or analysis, AI analysis that they are doing on the payments, but collections. I don't even know if I have access to it, honestly.
Me: Let's find out.
Them: But. Yeah, we are experimenting it together, but, yeah, this one, I guess. They have identified this customer as a customer with bad payment behavior. So usually it's a signal to their 116 days late. It's a signal to either put them on hold. Stop selling them until we receive a payment. Yeah. I don't know. What? Can we look at it from here? That might be helpful. I don't want to mess up anything for the team.
Me: Right. It looks like they do some sort of.
Them: They kind of record correspondences. They have send emails twice. And it calls anything. Like they have any calls. The transcript is here and it's recorded. And here I guess they give you suggested actions on the best approach for that customer. So. Yeah, I don't know. What could be the best way to connect this to? Because they kind of know, okay, if there's a promise to pay from the customer, they update. Or high rates automatically updates the payment date to a certain date and puts a kind of reminder that, okay, we're receiving a payment. But I'm not sure where is it all saved or. How we can easily extract it from here and share it with Palma. Some more accurate forecast.
Me: Yeah, no, that's fine. I think we were just curious because our thinking goes something light. Well, if, you know, they're able to identify the customer behaviors. Right? And maybe paint them more accurate picture in terms of when the AR team can in fact expect a payment to arrive. We would be curious as to their approach to get there. Right. How are they doing that and what's the user experience?
Them: Yeah. That's their main selling point. I don't know if they are just willing to give it away.
Me: No, no, of course. Of course.
Them: But let me ask around and see if that's been saved somewhere. All of the promise of pay and any communication with customers that might be helpful. Maybe we can trigger an automatic email and send it to pound for it to be processed or something like that. Let me ask the team.
Me: Yeah, no, it's okay. We just, we're just very curious because we actually do hear it across, like, prospects and customers, that it would be great to, you know, if Palm could essentially do something like this in our collections forecast, just to inject up extra layer of accuracy into the forecast in terms of when will their cash actually land in the account.
Them: Yeah.
Me: So we would be curious because we've understood a high radius, like you said, it's one of their main selling points. And we were just curious as to, like, how much setup is involved. We understand that they require you to create, like, each customer and then maybe, yeah.
Them: Yeah, yeah.
Me: The connection between invoices and mapping them to customers. And how much how much of. A process. It is. But yeah, there's probably other ways that it can be done as well. It's just interesting to see how others have approached and solved the, the same problem. It's basically, basically just that. So it's not something.
Them: Yeah, let me. Yeah, let me ask around, and I'm sure we'll find something.
Me: Yeah.
Them: But. I know they might be a bit tricky, but in Euro finance, I met some startup doing something really similar and it looked much better. And they were just across Christian from the stand, so maybe he did some connection there. And I'm sure they are going to be much more happy to help than high graders.
Me: Okay? No, no, no. Not expecting high radius to help us out in any way.
Them: It's always nice. I think it's. It was construct. Let me. Now. Maybe not. I think that's correct because they were exactly across. Stood. No. AI that collects your cash automatically. And I think they. They do. They have a logic like that. And it's from what they said and from what they show, it's much more smart than what I've seen. With high. With high. Ready? Yeah. With high radius. So yeah. Maybe.
Me: Gotcha. Super cool. Thank you. I'll check it out.
Them: But, yeah, either way, I'll ask. Yeah. Yeah. To get some more insights from. From the high radius process, and I'll let you know.
Me: Amazing. Thank you. Is there anything else? Sorry. Now, I'm going back and forth here, but in terms of the Cariba forecasts, do you feel like we've covered? Most of it.
Them: I would say the primarily. Let's say drawbacks of Caribbean what we are missing. I think we covered.
Me: How? Yeah, just, like, if we just do one step further, like variances and stuff. How do you. How do you work with your forecast in Kariba to identify where you might be able to improve. And so on. Is that an easy workflow or is that.
Them: The bunus. No, no, no. Variance is there. So no comparison. This is what we are not doing either. So basically the. The main variance is, is the next day when you open and you are expecting, in a good case scenario, if you were expecting to have certain amount and then suddenly the forecast is gone and actually there is no cash outflow, that's a good case scenario. You just have a bit more cash there. Here.
Me: Gotcha, gotcha, gotcha.
Them: Mental variance analysis. Good is improved our capacity, our brain. Anything that you can. Share that it's better than nothing. It's always. It's always good.
Me: Sure.
Them: But I would, I would say so in reality, this is what we. Because we, we start working, I would say, with forecast potentially the last two, two months, like properly. So these, these observations which we shared, these are the drawbacks which we found exactly by seeing, like, okay, we have the effect in that cash outflow. It is lower or higher. Why did it happen? And then kind of like discovering. So potentially there are there. There are more. At the same time, at least not that significant. The rest I would say there they're very the rest variances are coming from payables popping up in the system or other way around, not even being in dynamics. But they have to be paid urgently, so kind of ad hocs. So which are more difficult to anticipate, but potentially could have been anticipated if there is a pattern. So the pattern we didn't check if like if they are regular or happening. So some big ones I know that they were really a one offs. Others are not. And this is what I was thinking also for. For Palm, let's say, whenever there is a certain forecast and what we discussed also in our workshop, right? That Palm takes several repetitions from the past, right? In order to create, let's say, a trend and so on. So it would be good if. There are some, let's say possibility. For instance, there is a one off payment which is we have even like sometimes couple of millions which is a significant amount to kind of untick it from the learning or considering for the. For the rollover because we checked them, they are really one off and they will just skew. The whole. The whole. Kind of future forecast if they stay there.
Me: Yes. Very true. We. We have thought about adding that as a step to the very fire flow. If, you know, like, in the app, we have this, like, you can verify. And I essentially is, you know, the act of matching the forecast to an actual. Yeah, we've thought about adding it there. We've also thought of just. Like in transactions table such find any actual induce market as an outlier essentially.
Them: I think that would. That that function is definitely needed because. Exactly. Even. Even if there's in transactions, I don't expect it to be lots of transactions like this, for instance. We don't care if it is, let's say before below million. Well, for some entities, of course, but. But if it is something really big, then it is not that much work to to to go to transaction and just ticket that it is an outlier.
Me: Agree. That makes a lot of sense.
Them: I think from our side we can. First of all, I think it makes a lot of sense. I think FEMA says what we can also do. I think if we dive, if we go into this direction, Is to also make it easier to identify those outliers. Because I think both visually but also, I guess, amount wise, I think it's not, it's probably not very difficult to identify ones that have not seen before, ones that are not within, I think, the boundaries that we expect. But what I've been doing, I think, over the past weeks was also life a bit deeper into the forecast that we produce in our system. So for all of our customers, And it's. It's indeed that outliers do play quite a. Quite a big role in performance. Because if you want to take into account the outlier, the forecast looks totally different than if you don't take it into account. So I think it's very. It's very relevant and I think very important, I think, to. To tackle this.
Me: Could we. Sorry, Rodel, a question. Could we already know. A bit naive, but if you want to. If you just send us the transaction that you want to exclude, could we manually just exclude them from the data? For now. To try it out and see if.
Them: We could. So I think what, what I. What I would do is I would try to see what the effect would be. So if we have an example, I think that makes it easy to test out the effect, and I think we can share that as well. I think, to have it fully in the system and then repeatedly use it. That is, I think, a bit more difficult. But I do think that it's. It's not a very difficult functionality to have. I mean, I can. I can share one example I have with an example of 11 million. And do you know what, what, what might be helpful as well for me, because I really found this transaction. By kind of. Not by mistake, but by chance, because I was checking other parts for financing, and then it was a transaction which is kind of not. I don't know. We didn't have this currency or in such amounts, this currency. So it's it. It is. If the system can, for instance, also tell us. You know, all good. Let's say this is maybe a forecast. Something didn't match, but in general, this transaction actually looks odd. For. For this account. Let's say you never paid this amount in this currency, but usually you pay everything in another currency, but then suddenly it is this one. So if the system also kind of. Kind of flag it. That's also something. And then afterwards we don't expect system to understand what it is. But at least if it is flagged, then we can investigate what's what's happened and why it is. So why it is such a strange amount or whatever. Yeah, I think to share a little bit of my perspective there, I think it makes a lot of sense, I think, to have this function of the ultimate transaction level. I think that is very, I think, very much necessary to exclude outliers and I think to really investigate whether something. Whether something looks odd or is odd. I think one other thing I think that might be interesting in this is something that I would also be interested to hear your perspective on is also on an aggregate level. So let's say we produce forecasts. And then suddenly we have actuals come in and then let's say we are the next day. It's totally off. I think, from what we've forecasted. Is it? I guess that is also probably relevant to know kind of yesterday was not aligned with what was what was forecasted in the short term forecast. Yeah, it was. It is also. I just don't know if daily it makes sense because maybe we were expecting 100 million outflow Monday. It didn't happen, but it will happen. Tuesday. So I don't know. If daily it makes sense of maybe weekly or every, I don't know. Yeah, weekly might be the best. Yeah. Yeah. It's just I think. I imagine that. I think both on transaction level, I think we can dive deeper. But I imagine that as a first level of going into the problem, I think it might be relevant to see this is like a very big amount, like aggregate amount on the account for the week. Doesn't make any sense, and it's kind of in the variance analysis angle, of course. And then I think, dive deeper into what is actually driving that difference. And then indeed, like, being able to flank specific transactions and then removing those from the forecast. Yeah, just thinking out loud as well, but makes a lot of sense. Thank you.
Me: Yeah. Yeah, yeah. But in terms of that, almost like normally detection sounds doable. Like we. Yeah. That would have been interesting thing. To look into.
Them: Yeah, it's. It's been on our minds as well. I think it's. It's within the same domain of forecasting. It's just a different way of looking at it because you want to see instead of what, how closer to you. What do you expect it is more when. When is it? Not expected. But I think that there's definitely an angle that will become important. Absolutely. Sounds good. Thank you.
Me: It was very helpful. It's always good to see a little bit like people even just seeing user interfaces and understanding a little bit better. What other systems are currently offering. It helps us also, you know. Think ahead. So that was super useful. If you think of anything else, you know, just let us know in the Slack Channel or. Or anything. Great. Yeah. Looks like. We're pretty much done, then.
Them: Sounds good. Perfect. Sounds good. We're happy to chat and look forward to the seed.
Me: That's super nice.
Them: Thanks a lot.
Me: Thank you so much.
Them: Thank you. Have a nice afternoon. Good one.
Me: Like what?
Them: Bye. Bye.
Me: Five.