 So, IT financial management actually touches about 50% of the reference architecture. And that goes back to what I presented in the beginning around that there's a lot of data flows that is happening and there's a lot of functional component that has got some minor trimmings in terms of what are the attributes that are maintained on these objects in order to truly support financial management. Let's look at it in a little bit more detail. Well, the first thing is that, and I mentioned that in the beginning, but it's very important to stress, the fact that we now have a service backbone that goes all the way from conceptual to actual allows, and we have connectivity through it, allows us to do much, much better cost tracking. Today, in most IT organizations, the requirement to deploy is kind of a fussy area that doesn't really connect you between what was originally kicked off and what is actually running. And so what you do is, the one, you service dice everything. You make sure you describe everything as service. You build the service budget and then plan out, build out something you put into production. And then you track what you have in production. And all of that cost that you track, you aggregate backwards through the chain so you can track it all up at the conceptual level. And you can do that fully automatically if you have the data models in place. Whereas in many organizations, it's a very complicated job at the side, run through window invoicing and cross-charging and what have I, do much smarter here and much more fine-grained. It's a little bit like when you first learn to program and you are learning about recursive functions. And the first time you write a small program that works with recursive function, you look at it and say, it can't be true. That was just too easy. It just works by magic almost. It's a little bit with this one. Once you've got it in place, you can actually do magic in terms of tracking. So moving on, if you know where that, let's just look at not the entire hierarchy. We don't have time to go through all the details here, but we'll just look at the employee expense management service, hands and the way it gets a new instance developed. And we will start at the, in how you describe the system. Just recalling what it is here. So we will look at that and then we go back to how you capture it in the planning space. So essentially, we've gone through it. We, Hans has deployed his system. It's up and running. There is a charge-back contract that has been created. The owner is Hans. It's associated with the, so the price structure that is associated with that system might be something like that the hosting is being paid for by the cost of the hosting. The FTEs that is being used to support this is charged two and a half K per FT per month. And the backup is charged with what the backup is actually costing. And I should note again that here in the financial management work that has been done in 2.1, we are primarily cost-based, but the system would actually also work in other models where we have cost plus or a price based on the value of the service and not the cost of the service. Okay. So at the collection time, at the end of the charging period, we need to create a charge-back record. And what is happening is that the usage record will be produced and there will be a usage record here for the hosting component that basically says, for period of May, you will cost, you have cost me two K dollars. And that's the hosting service that has produced its own charge-back record that is now being fed into my employee expense management system as a usage record. And similarly, there is usage for the people that has been running support. They spend 243 hours in the support systems. It could also maybe be a number of tickets or something else, right? And the price for that is 3.6 K dollars. That's what has been collected from the support guys. We might not charge because I said, well, we just do a flat charge upwards, but that's actually the cost that has been collected. And finally, the backup says you back up two gigabytes of data. It costs you one K dollars. The charge-back record will then be compiled from that. And for May period, it's a hosting two K, FTE, there are two FTEs, it'll cost you five K because that's what we have. The contract says it's two and a half K per person. Even though the actual cost will lower, right? And the backup, two gigabytes, it's going to cost you one K dollars because we're just giving you on the charge, total eight K dollars. And the reason why we know what to collect is because we have a service model that tells you the hosting service, no, sorry, the employee expense management service is delivered by some software that runs on hosting and runs on use some backup and use some FTEs. So the model tells us what to collect and what to compile the charge back from. If you then move backwards into saying the investment portfolio, how does it work from an investment perspective? And that's kind of where it all gets together. Well, it all started, if you remember in the beginning with that, there was some demand coming in that was portfolio backlog items. That essentially is that I want something more to be developed. And we have defined now, listed in red here, some extra attributes that I see for IT compliant modules must capture. Like what is the investment budget associated with the portfolio demands? So somebody has estimated that it will cost you 36 K to deliver the next version of the employee expense management. And by the way, they also estimated when it would be complete, essentially. And then you build up a proposal that is a scope agreement. And based on that, you go down and associate an IT budget item in the financial side of the house. Where you would sign up the budget and say, yeah, you can get 36 K for that. And by the way, we also want to have some budget allocated for running the service 28 K. And that is now being tracked in all of these various components as something that is being budgeted. And approved, finally, that's associated with the proposal. Is it approved for this budget and then it gets approved? And maybe the status act of that in blind that we're actually developing it right now. We can also, at the service portfolio level, then track what is the total cost of ownership budget that is budgeted for it, which is the 36 plus 28 K dollars, that's 64 K dollars, but what is the actual? Here it says the same figure, but that's actually only after the fact. You need to track it as you move along. And how can you do that? Well, that's back to what we just looked into. It happens in R2F with the uses and the charge back component. Because as you track that information, you can essentially from the charge back and users record, you can compute every month what is actually being spent. And by the way, it's not only what is spent in production, but also what developers are spending when you develop the product, because you allocate resources in order to develop. It's FT, you just allocate it from the catalog. It's just a resource like any other resource. You allocate the servers that you test on. You allocate the test licenses you need, et cetera. So you can get all of that information back. And then you can feed it upwards to the project into the service portfolio, and you can track what is the actual spent. The details need to be worked out in a much bigger spreadsheet. We don't have time for that today.