So, let's move on to our next presenter, Alexander Pick from the OECD, who leads the Tax Data and Statistical Analysis Unit at the OECD's Centre for Tax Policy and is responsible for the Revenue Statistics Initiative, which through my own involvement via WIDER's Government Revenue Data Set project I've used very heavily, so it's great to hear from Alexander. Good afternoon. I'd like to start by thanking everyone, especially the organisers. It is wonderful to be at this event, which has been fascinating up until this point. I really hope that that doesn't change for everyone now. I should also clarify that, as was just said, I am at the OECD, but I work on tax data and statistical analysis, not on the two pillars. So, if you're waiting for any reason, I'll be in the corridor after the event rather than for this occasion now. So, thank you very much. This is an opportunity to talk through the Global Revenue Statistics Initiative, and I will do so once I figure out the buttons. Now, here we are. My presentation has four sections. First of all, just to explain what the Global Revenue Statistics Initiative is. I would shorten that to GRS each time, but then it'll be a bit confusing with the UNU wider, so I'm going to keep on, and I've asked for your forbearance, keep on referring to it as the Global Revenue Statistics Initiative, or I might shorten it to RedStats. Then I'm going to talk about the process of data harmonisation and the extent to which that relies on dialogue between the OECD, partner countries, and also regional organisations and donors that are involved. And then I think what's perhaps the most important aspect for this session, which is, I think, very well titled, How You Move from Good Quality Data to Domestic Resource Mobilisation, and finally some headline results, which I think not only will I hope show the applicability of this data, but also bring much needed variety to what is otherwise a very text-based presentation, so apologies for that. So, to start with the first question, what is the Global Revenue Statistics Initiative? Well, it is a means of providing harmonised text revenue data that is comparative across more than 120 by the end of the year, hopefully 130 countries, all according to a common classification, and I'll come back to why that's important in due course. Each year we produce four annual publications that show this revenues, this harmonised data for different regions. This is the African report and one lucky winner can walk away with one of these. We also produce reports for Asia and the Pacific, Latin America and the Caribbean, and of course the OECD, which is where it all began. It is intended as a key input for tax policy makers and administrators and also researchers, I should add very much for this audience, that provides information on the level of tax revenues, the structure of tax revenues, and indeed for some countries, non-tax revenues, as well as changes in these revenues over time. As well as that, it is also a tool for capacity development and a platform for communities of practice and regional dialogue, which often but not always takes the form of technical workshops. We are aligned to SDG 17 and the Addis Ababa Action Agenda, and just to return to the SDG 17, I think we contribute, we try in a variety of ways. Of course there's the contribution to domestic resource mobilisation monitoring. We also would like to think we contribute to the DRM agenda itself and also develop statistical capacity. The next slide as well I think picks up on another SDG 17 point, which is the extent to which it is an initiative that is based on partnerships. So for OECD countries alone, obviously it's a fairly OECD-based, but once we are working with developing countries, you see the quantum of partnerships that are involved and indeed required in producing harmonised revenue data, but also in ensuring that the revenue statistics initiative meets regional demand and meets the demand of countries in that region. I hope you don't mind it. I'll take this opportunity to thank Norad, Peter over there, but also other people who are the donors that contribute to the initiative. As you see, there are a lot of them and this is, I think, will be explained by the intensity of the production process. Just to draw your attention, for example, so for the Africa publication we work with the African Union Commission, both on the economic development side, but also Stetafrique, which is two very important role players, as well as the African Tax Administration Forum, which is an increasingly vocal and important part of the conversation representing African voices in international tax negotiations. So we are not only grateful, but we strongly rely on these partnerships. Similarly for Latin America, we work closely with the UN, with the UN SEPAL and other organisations and Asian Development Bank, but also Pacific Island organisations for the Asia-Pacific publication. So to return to the key issue, the key value addition of the Global Revenue Statistics Initiative is this ability to harmonise tax revenues at a very granular level over a sustained period of time for all the participating countries. And we're talking about countries, as you'll see, whose tax-to-GDP ratio ranges from anything from 6% to north of 40%. So the key is not necessarily whether a country has a very well-developed tax system. Really we can work with anyone so long as they're able to provide us with the data starting with a high level, but we can work together to, over time, building on a relationship that evolves and trust that deepens to provide increasingly high quality data. So the value of the OECD classification, as contained in the Interpretative Guide, it provides a set of principles to define and classify taxes, as well as instruments that should not be treated as taxes. And this ensures consistency across countries. Moreover, the OECD classification is not set in stone. It is constantly updated. We work with statisticians across 120-plus countries to understand what are the trends, what are new taxes emerging, and this is not a quiet space at the moment. And so this process has been continuing since the 1970s, and each year we update the Interpretative Guide to make sure it remains relevant to the global international tax space. It's also, and this is very important, it's entirely consistent with other well-known statistical classifications such as the System of National Accounts 2008, the European System of Accounts, and the IMF Government Finance Statistics Manual, 2014, which in turn means that it is possible to map the OECD classification and the revenues allocated for each of the countries to these other classifications, which we hope is not only helpful for researchers, but actually for the countries themselves, as they are sometimes required to report on various, through different different processes. And it should be noted that other statistical publications also draw on revenue statistics data from time to time. I think a key point I'd like to make in this presentation is that harmonization is a two-way street and slightly glibly, I've called it a busy two-way street, perhaps influenced by too much time in Paris. This is, I think, the idea that the OECD sits in Paris, collects data and then churns it out on its databases, couldn't really be further from the truth. For all of the countries that are covered, there is a strong relationship that has is constantly renewed on an annual basis because of the annual publication, the annual data submission process requires a back and forth. And not only that, but also when countries join the initiative, then it's an extraordinarily intense period of discussions around how to classify such and such attacks, but also just issues around possible gaps in data, possible issues, okay, so you can provide central government, but also what about local government? These kind of conversations are not only useful in terms of the data that they generate, but actually they allow administrators, our focal points in countries, they give a reason, a justification for reaching out to the Social Security Fund or to local governments and saying we have this mandate to provide data at the OECD, can you actually give us this because we haven't seen it before, and this is often the case with customs data as well, and in so doing it actually has been shown in a number of countries to facilitate their own data sharing across government, which I think is a valuable thing in and of itself. So this dialogue has two main purposes. The first is to match national tax categories to the OECD classification, but also as I've said, to obtain complete information on revenues for different categories and different levels of government over time. And we start from the bottom up, which means that we've got the greatest chance of ensuring granularity and rather than just taking a top-down approach. As a result of this work undertaken with the partner countries, we are able to produce data that in the end can be, is strictly comparable with all the other countries. And in turn, this forms the basis of key indicators on the level and structure of tax and non-tax revenues, not only across countries, but also it allows us to generate regional averages, and I'll come to that back to that in a second. I should just say, so I haven't mentioned it previously, is to join revenue statistics, we need a buy-in, sort of a signed response from a Minister of Finance or perhaps a Commissioner General of a Tax Administration, and that mandate in itself is important for the focal points to get the information that they need. Moreover, our regional partners are often extremely helpful, not only in making the required connections, but also validating and double-checking the data. And finally, the point very important to make is that we don't publish any data until a country has had the final opportunity. They validate whatever goes online, so nothing will go up or be published that hasn't got the government say so, green light. So how does this actually contribute to domestic resource mobilization? Well, I would sort of break this down into two questions. First of all, it's a basis, this high quality and harmonized revenue data are a basis for policy analysis. They allow policy makers to answer fundamental questions to understand the potential for enhancing DRM in their country. So what is the level and structure of tax revenues in my country? How do these compare to other countries? And how have revenues evolved after tax reforms or following shocks, for example? The revenue statistics data can also be used to produce more complex indicators to assess specific aspects of a country's tax system such as the effectiveness of its VAT. We have also developed specific tools and online training to promote data analysis and these are all available publicly free of charge as is all the rest of the information that we produce. Each year and for each report we produce special features on priority issues for DRM, often making use of the harmonized data we produce and often written in coordination with our partners which helps to ensure their relevance and also the voices of our partners are well heard through the initiative. So for example, we used revenue statistics in Africa data to analyze the possible impact of the AFCFTA on trade tax revenues or another to harmonize the quantification of debt servicing costs as a percentage of total revenue. So these I think are important questions that harmonized data allows us to have a conversation on equally for revenue statistics in Latin America and in the Caribbean. We looked at tax expenditures this year so which I'm glad was timely. But at the same time it's not just about policy analysis it's also a platform for a tool for capacity development and a platform for knowledge sharing. I think this is something we are very keen to emphasize. It's an integral part of the initiative not only for capacity development for countries but also for regional organizations themselves and we're thinking not only about analytical capacity to use data to inform tax policy at a national or a regional scale but also statistical capacity for producing comparable and detailed revenue data. Annual data collection as I said involves this transfer of knowledge and skills between countries, OECD and partner organizations and that's sort of an ecosystem whereby this knowledge can be shared in often through these annual technical workshops which we are increasingly as coverage grows increasingly fundamental for communities of practice around the production and use of high quality revenue data and knowledge sharing on common challenges emerging and emerging issues as well as successes and failures. As I said because the initiative has expanded so to have these communities of practice. So that allows me and I think I have three minutes for some high-level results perfect. So this is slightly old data but we don't have a complete set of data for 2021 and I should say that we have a the intensity of the data gathering process means that we do have a bit of a lag in our data so by the time we publish this report for 2023 this will mean that we have a complete set of data for 2021 which isn't necessarily ideal for that immediate policy response but at the same time we've looked into getting it quicker and it's you know given the capacity constraints it's not always possible. So there's a trade-off there in any case for 2020 this is as you all know the year of the COVID shock and we see the range of tax to GDP ratios across the different regions I think this is a fairly explanatory but it's a nice wheel and then we also see and this is on one hand a staggeringly boring slide but we've heard a lot about how tax revenues stagnated across 2020 and here you are it's beautifully just very straight lines with a bit of a dip in 2020 but this is making use of you know extremely to get that very boring graph there's millions of data points to go in there so you know it's it's nice that it can be simplified to this level and in the this year's publications we see we will see how Latin America takes back up Africa actually probably is going to a flat line and and OECD somehow kept going up a bit Asia-Pacific because we only have an average going back to 2018 we haven't shown the longer time frame but we could include that as well and we will do in in the future and finally this is a nice slide because it shows the importance of different tax types in different regions so again the the tax mix is hugely important for tax policy makers the headline message here because I don't have much time is look at the OECD average look how different its tax structure is with a much greater role played by direct taxes income tax social social security contributions than in developing countries where taxes on goods and services are much more prominent interesting also that the Africa average and the Asia-Pacific average are very similar whereas the lack average is slightly different because social security contributions are more important PIT levels very low so this are some links which you know I don't is it worth putting these up I never know I mean if you can find this slide later you will be able to click on these links for now I think this is almost entirely unhelpful but it does remind you of my name and and that's me and this is just a nice picture because in May of this year we were able to have our revenue statistics in Africa workshop in person for the first time since pre-covid and I tell you it's um it's a wonderful experience to be able to bring well tax policy makers and statisticians from 30 different countries into the same place to hear about their experiences to learn and it's always a wonderful experience I think that sort of epitomizes the the value addition of global revenue statistics thank you very much for my time I'm sorry for talking so quickly


Hello everyone. Thanks for attending this session. My name is Nim. I'm working as software engineer for Google Cloud. Our team is mainly responsible for maintaining the hypervisor and virtual machine monitor inside Google and Google Cloud. Today, the topic of the talk is hypervisor-based integrity. As you can probably tell from the name, we are trying to utilize the superpower given by the hypervisor and hardware to provide the guest kernels running inside the cloud environment. So some high-level disclaimer. This is not a statement of direction or planted investment by Google yet. We are exploring this as possible security mechanisms and we are seeking feedbacks from the big communities. A background on why we are heading this way. So Google Cloud offers a product called Show to the VM. In fact, that's a default VM type if you try to create a virtual machine inside Google Cloud. As you can tell from the name, it can be some enhanced security features, one of them called secure boot. On high-level, in case you're not familiar with it, provide integrity check against firmware, bootloader and kernel during boot time. It will use the certificates and to verify the signature of all the modules and has been sent correctly, all the drivers and all the binary is trying to load. So it gives you a guarantee like by the end of the boot, everything should be in a very good shape. Nothing has been modified or has been hijacked in any way. After that, most kernel modules, if you try to load additional dynamic kernel modules, they will be protected by the module signers. So that's code in the kernel, which will do signature checkings against the module you are trying to load. That's all good. But in real life, attackers can still find different ways to gain like highest privileges inside a running kernel. If he can do that and he can modify the code page or call back in some special way, like all the security gate we put in place cannot be trusted and we could put user applications in a risk state. The goal is trying to protect the kernel even at runtime. Since we already have all these green box checked during boot, we are trying to extend what we can and help make sure like the kernel at runtime is also protected and can be trusted. If kernel has not been modified in any way and running as expected, the user application can feel much safe about it. And one more thing is the protection we put in place that cannot be able to turn off from the guest, because I mean rootkit can gain highest privilege. If he can change the settings in the guest to turn off the protection, then the protection is not that strong. So let's talk about the thread model here. So we assume the attacker has the following capabilities. So it can gain ring zero access. It can have arbitrary read and write permissions. So it can read and any kernel memory address and write any value to any kernel memory address. So how do we protect the guest kernel based on the thread model we just talked about? First of all, we want to make sure there's no intended modifications on the kernel code segment and read only data segment. And this is very obvious. We have very well written code. We don't want it to get replaced by some molecular code. Second of all, we want to make sure the code execution, no code execution from other part of the kernel space. Data segment should always be read and write, but not executable. And this is where bubble overflow attack happens and we want to block that. And third, and we want to make sure there's no intended modifications of key kernel data structures. For example, system call table, which is a table of functional pointers. The hackers managed to replace it with something else. The user may get monitored or hacked without realizing it. As an example is control register like CR0 or CR4. There's a bit in the control register in the CR0, which is read write protection. So if you send off the bit, the kernel world, the processor will allow you to write to a read only memory, which is not ideal. And there's other important MSRs, like there's people talking about system enter MSR. And utilizing that MSR, they can hack some system calls. Of course, similar to system call table, there's IDT interrupt descriptor table and GDT global descriptor table. Both of them have some functional pointers. We want to make sure it never gets overwritten. Of course, last but not least, we have the page table, which has mapping from virtual to physical. So if people hacks mappings, we can redirect the code execution to some other place. So why we want to use hypolysis as another security layer? Our understanding is there's always a risk of protecting guests from within the guest. Because we already did a lot of kernel handling work in the kernel space to make it harder and harder, but it's not guaranteed to be impossible. Rootkit or Attacker can still gain highest privilege and read and write any guest memories if they want. And it's not easy, but it's still possible. Anything we put in kernel space could be risky. But on the other hand, if we guarantee kernel code never changes, then basically in return, it will make sure all the security checks we put in place be more robust. So this is not a replacement of all the kernel handling work we have there. We hope this is just an enhancement layer, like make sure whatever you put there is correct and remain correct for the entire lifecycle of the VM. On the other hand, hypolysis has almost one-to-one mappings to all the protection we want to achieve. The hypolysis can control read, write, exclude, bit, or page align guest memory region. Utilizing the two-dimensional pages like EPT or NPT for AMD, we can set up the permissions which guests can never change. And hypolysis can protect unsafe modifications of counter-registers and MSRs. We can just configure the VM exit on those write to MSR or counter-register, and then we can do double check whether that's legitimate or not. And hypolysis can also protect the key kernel page table. There's a new feature called hypolysis managed linear-adjusted translation from Intel, which allow you to set up page table mappings controlled by hypolysis and guests can never change it. And most importantly for us, for Google Cloud, all of our guests, all of our customer machines are already running in virtual machine mode. We already have a layer underneath all those VMs. We are not trying to introduce another layer of complexity here. We are just using the existing layer to make everything more robust and more secure. So how does everything work end to end? Here we want to introduce a new guest security kernel module. This module should be loaded at boot time, ideally by the end of boot time, so the kernel has already set up all the page table, IDT, GDT, system call table, etc. It should be signed and protected by the secure boot, so it can be trusted at boot time. If anyone tries to modify it in some way, the secure boot will fail. And after it gets loaded, it will check whether the hypolysis supports special integrity protections. If it does, it will try to identify all the kernel code data segment and address all the key data structures and send a please protect me request to the hypolysis. And then we need to wait for the acknowledgement from the hypolyzer, because we don't want to jump into the runtime, so everything becomes a little bit out of control. During boot time, everything is still in control and in code shape. On the hypolysis side, during boot time, it needs to decode the memory, segment information sent from the guest, or modify the second level translation table to set correct read write execute bit for the specific memory region. And it will config the VM exit on MSRs and control registers. After that, it should acknowledge the request and let it continue to boot. We just a few articles we need to call, so it should not have significant impact on the guest boot. During runtime, the hypolyzer and QMU or VMM will just enter in EBT and NPT access valuations. And if that happens, you can config one of the following actions and either kill the running VM and dump all the memories for analyze. That's for the people who care a lot about the security and won't make sure nothing wrong should happen. And for the user, we would expect we will just log up critical event and notify the user and let them decide what they want to. Meanwhile, on the other hand, we do the same thing for the control register and MSR modifications. And you may be wondering like, you know, in runtime we can add dynamic kernel modules. Those kernel modules are executable. So how do we handle that? Our recommendation is much safer to do not do that. But if you have to do that, and we have APIs exposed by the guest module, so we'll modify the kernel code a little bit. So first of all, the kernel code will allocate read and writeable memory region, then copy and run into it. And once the verification is done, it will call the API to change the code segment of that memory region to be read and executable. So I probably will make sure like the code segment never change after the first time you load the kernel module. You may wonder like what's the performance impact since we are doing a lot of stuff here. And for memory access, the impact should be minimal. Mainly because we have support through the hardware, Intel, EBT or MD and PT. If there's no validation happens, there should be no impact at all. But if something happens, I think it's okay to pay some extra cost on the VM exit to determine whether the operation is legitimate or not. And from our prototyping and testing, those do not happen very often. If it is a HLC kernel. For control register and MSR, the module-specific register, the impact should also be minimal. Because we don't expect a lot of modifications on a typical kernel runtime. If you are running a nest virtualization, it's completely another story, so we don't recommend people to run into these scenarios. And for the PgTable translation, it needs hardware support, but currently only limited to Intel at the lake. So it's not there yet. We cannot match it. It sounds straightforward, but it has a bunch of technical challenges. Two major ones is like how do we distinguish between legitimate kernel modifications. There's a bunch of reasons you can see we list here one to modify itself. And we need to work with our customer to disable those special scenarios in their image. Or we need to decode the instruction pointer and go through a call stack and whitelist those operations. Another major problem is when set memory permission, not all segments are nicely aligned. If we have one page and because when we set permission, it's on the page level. If we have one page that is shared between a code segment and a data segment, it will be very hard for us to set the correct permission on it and we will have a potential problem here. To mitigate this issue, some changes in the kernel need to happen to make sure all the code segments, all the different segments of kernel is nicely aligned. So here's a quick example of what it looks like if we turn on the protection. We have guests running on DBN10. After the kernel boots, we map the entire kernel code segment as read and executable. We have a bunch of EPTA violations right away, but if we go through a call stack for each of them, it comes back to the same function, which is a text book. The description of this function clearly says it's trying to update the instruction on live kernel. So this is a valid case for kernel modifications. After we remove that particular module, after that the guests running smoothly without any further violations. This is a very good example to show you, like, if we config the image correctly, any violations, any access violations, will be a strong hint of possible attack. Now let's talk about to support the protection we just mentioned. What are the changes we need for KVM and QMU? First of all, we want a common interface to turn on the protection. As you can see, during boot time, the guest agent is sending some message to the hypervisor and VMM. So currently we are using select MSR to these configurations. It's not ideal if we can allocate a special hype call just for this purpose. It will show that this is for VM only and it will avoid a lot of confusions. And once people agree on the interface, API, what the hype call looks like, any hypervisor or VMM can implement as a support for this API to provide the same level of protection, no matter where the VM will be landing. Like Azure AWS or Google Cloud or QMU, they can all implement the same APIs, so the guest can move freely around different providers and gain the same level of protection. We have RFC sent out a while ago, so that's for adding a hype call called ABM, a hype call U call. So this is a hype call we want to tell the hypervisor to hand over to VMM to handle this special hype call. We have a link, you guys can review it. So why we need this change? So today all the hype calls are handled inside KVM. It never costs any VM exit. And we want a hype call interface to pass a control back to VMM. Why we want VMM to handle this request instead of KVM? Because VMM is responsible for setting up the guest memory mapping and should have knowledge or should control the permission associated with it. And what's more important is it can simplify this part for live migration because during live migration, VMM could just create the same guest memory between a pilot permission because it has knowledge of everything. And we can keep this KVM simple. KVM just need to expose API we need to turn on the production and all the status is maintained in the VMM instead of KVM. So once we have the hype call defined, we want to define the message sending from the guest to VMM. This is a simple proposal we put here. We want called HPI request. It's a hypervisor based integrity request. And we have a version and operation code. So for operation, it can be set memory protection, et cetera, et cetera. We can extend it for future usage. And for the message body, it only need to tell us what's the PFN, page physical number, how many number of pages you want to protect, what's memory permission you want to set on those pages. For the memory permission, it can be read and execute or read and write. Never allowed execute and write at the same time. And once the request is complete, it gets able to get the result from this written code. So that's for the protocol, for the guest VMM communication protocol. Other than that, they correctly set the memory permission. We need to call the KVM set user memory region IPTOL. Unfortunately, today's current call only supports setting the memory as read and executable. But we want read and write, not executable. This is something at the last part today. We will try to extend it. And we also want to expose ability to do VMM exit on control register modifications. Because there's a lot of bits we want to protect there. And the hardware Intel AMD, this part, if you can fix, for example, the VMCS correctly, we can get to exit on control register or control register 4. And we want VMM to make this call whether we let the motivation to go through or we should not. And last, this is basically support the new Intel hypervisor management linear address translation. This is new hardware. I don't see what is there. I hope Intel or some committed members or us will work on the support for this together. And for the future, once we have the protection we talk about in place, we can extend this guest QT module to expose APIs for any kernel code to consume. It can be a driver. It can be a security hardening code inside the kernel. So they can call the API during boot, locate a memory and write to it and then market as read only. So we will send this memory segment to the advisor at the end of boot. And then we make sure those memory will never change during the entire lifetime of the VM. So yeah, all the kernel security and driver modules can take advantage of these to protect themselves. Now let's talk about some other security considerations. But first of all, all the protection we talk about today is built on top of skill boot. If skill boot is broken, our guest agent could be changed and we cannot trust the message it sent to us. So why can we trust skill boot in Google Cloud? For Google Cloud, all the guest firmware is actually immutable. We inject the guest firmware during boot time and copy it into the guest memory. So even if you manage to change the firmware in some special way during runtime, after you reboot, you will get a fresh piece of firmware and restore back to a good state. A lot of firmware integrity check is actually happening outside the guest. We know that's critical piece of code. We want to make sure it's doing what we expect. So a lot of security check, signature check is happening. We upload all those logic into the VMM processor. It's not happening inside the guest. And for important security boot variables, primary keys, signatures, they are stored on remote server instead of your local disk. So there's no way a guest can skip UV and skip our firmware to modify those variables directly. One popular attack against skill boot is through system management mode, or the SMM attack. To reduce the attack surface, the SMM is completely dropped from Google Cloud. We don't support it at all. But the production is not perfect. Even if we guarantee the kernel code stays the same through the entire runtime, and nothing gets executed outside this kernel code space, there are still possibilities people can use something called a return-oriented programming. Drop attack. What it does is trying to find some instructions on your executable region and train them together to achieve some special goals. For example, if people use drop attack to modify the kernel page table, it will still break the protection because you can modify the page table translation and point the kernel code to a different memory location. And if that happens, that memory location is no longer protected by any EEPT or NTP, so the hacker can do whatever they want there. Miticate is a problem. I think who knows, this randomization is very popular today. Let's make drop attack a little harder. And yes, ongoing work for the kernel control flow integrity. Make sure to make it harder to happen or make sure it's never happened. And yes, hardware spot, like the hypervisor managed linear address space translation we talked about earlier, where you can make sure the address space translation is happening on the hypervisor side. So let's avoid people hacking this page table in some special way. To summarize this presentation, we are trying to propose a hypervisor-based mean-forced protection for guest memories and system registers. And we want to also provide a parallel virtualization interface to enable this protection. And we want to enable security by default. This happening, we are proposing here to extend this keyboard and provide runtime protection for kernel integrity. Thanks. That's it.


Hello in this lecture, we will continue calculating depreciation. We are now going to move on to the double declining method We have in a previous lecture taking a look at the straight line method We're going to use the same numbers here and plug them into a similar problem working the double declining method We're going to look at the pros and cons and the differences in the calculations between these two methods and See what those will be. We're going to use these numbers over here We're going to put the calculation for depreciation into this area here We'll then put that into a shortened worksheet in order to see what the depreciation will be For each year in this case four years and then we'll calculate the book value for each of those four years Then we want to actually see this in context in terms of what will the journal entry be for each of those four years And how will that look on the trial balance in relation to other accounts? What's the effect on net income? What's the effect on assets? How does it look in context? So that will be what we will take a look at at this time. The information we have is over here We have the equipment costing 257 5 we bought it on january 1st So we bought it right at the beginning of the year so we do not have to worry about a mid-year convention in this case We're going to say that there's an estimated salvage value of 20 000. What is the salvage value? That means that at the end of four years in this case because the next one says the useful life is four years That's how long we believe the the Equipment will be used for so if it's a forklift or something like that We would have it for four years And then We would say that we would scrap it So even if it's not useful at the end of that four years Even if the usefulness of it is gone as a function in forklift in that example then We could still just sell it for the metal and the parts and whatnot That's what's called the salvage value And then we're going to have we see that we have the estimated units of production We're not going to worry about that at this time We will be using this information in the next example when we take a look at units of production And that will be an alternative way sometimes a more sophisticated way actually to better allocate cost in some way But of course you need this extra information to do that Which is costly to do and therefore some many times will actually estimate based on Time rather than performance And therefore we're also going to have this one piece of information do not depreciate the equipment below the salvage value So once again, what why is that? Why wouldn't we depreciate it through below the salvage value? Well, if we just think about what if there was no salvage value What if we thought that at the end of the four year useful life? It had zero salvage We would just have to throw it away then You can see it's pretty clear at that point then it would be not making sense for us to depreciate Beyond the 257 5 cost because if we did so then we would actually have a book A piece of equipment like a forklift on the books that not only has a zero value But it has a negative value and we could still be using that equipment So we can't really depreciate something below the cost, of course And if we think that we're going to sell it for 20,000 That's the new floor instead of zero being the floor 20,000 is the floor We can't depreciate but below the 20,000 because we believe that we can sell it just for scrap and whatnot Even if it's not functioning After at 20,000 therefore we need to stop the allocation. All right, so we're going to do that the calculations over here Once again, we're going to do the calculations in a bit of a longer format I do recommend setting it up in this kind of longer format way Because it can really give you a systematic way of calculating these You really want to get a system of calculating it so that when you look at different problems You can calculate it in the same way Note that these types of problems could ask you for the depreciation expense could ask you for the book value could ask you for the accumulated depreciation and therefore we want to set our problem up in such a way that we can Calculate whatever is asked for in an in an easy way And instead of us having shortcuts that basically calculate one piece of the equation And will not work for us in other pieces of the equation Also, we want to get the big picture Outlook in terms of what is really happening And if we do the full calculation in this way and kind of see all the relevant pieces of it That will make it a little bit more clear Of course after you do this you you may find some other ways that you want to calculate it You don't have to write out the entire thing every time But just remember if you do something in a linear formula Oftentimes it could be a lot more difficult to go back and look at it and say, okay Why is this long formula in the format that it's in If you do a calculation systematically kind of in a calculator one a calculation at a time Write those down then it's a lot easier oftentimes to go back and say I see what the work is happening here So you want to put your work in a way one that you get the right answer But two in such a way that you can go back to it Look at it and three you really want to put it in a way that you can set up other problems That may even at be asking for different information With the same format so that you can memorize the format of the problem So in this case, we're going to start with your one's depreciation We're going to start off the same as we did last time with the cost and the cost will be in this case I'm not going I'm just going to type it in there the 257 five So that's what we bought this equipment for And now last time we subtracted out the salvage value you'll recall in calculating the straight line method We are not going to do that for the accumulated depreciation method And this will kind of become apparent as we go But the first thing we will do is I'm going to calculate the straight line rate I'm going to do the straight line rate the long way and then show you how to do a shortcut way to do that So I'm going to take the cost divided by four years So I'm going to divide it by the number of years in the useful life this icon Of course here means division in the when we're talking about a Keyboard so I'm going to divide I'm just going to put in the four and so I'm going to write that out I'm going to show that we're going to take this divided by that and that will give us The straight line depreciation if there was no salvage value So this will give us the straight line depreciation if there was no salvage value So I'm going to do that calculation. I'm going to say it's the 257 five divided by four years So therefore if we had no salvage value of the 20 000 and we just calculated straight line depreciation We would depreciate 63 64 3 75 now once again Remember that under the street lamp method we did have salvage value and we took that out before dividing by four So keep that distinction in mind The reason we're doing this in this format this way is because we're just trying to get the straight line method Without the salvage value so that we can get the straight line rate and then double it So that would be the depreciation now we're going to have to figure out Well, what percentage of the of the cost is that so that we can get the straight line rate and then double it So in order to do that, I'm going to write that I'm going to divide it by the cost Remember the cost is just this number up here. So I'm just going to say it's the 257 five And I'm just going to take the rate and divide it by the cost And what we're going to do is I'm going to say that's equal to the straight line percent if there was no salvage value So let's do this calculation. I'll try to explain this a bit more. I'm going to say this equals the 64 3 75 divided by which is the slash the 257 five and enter that gives us a 25 percent Note that the reason it became a percent in this case if I go to the home tab And I go to the numbers group is because we formatted it as a percentage here So if it was formatted in some other way such as a number It would look by 0.25 make it a percent move the decimal over two places 25 percent Also, note that if it does not come out even if you're not divided by four in this case or then You could have decimals and you want to check that decimal function If something looks a little off in terms of rounding errors in that case So what we're really saying is that the straight line rate Uh, we we know that if we just divide by four we get to 64 3 75 if I want to think about that in terms of a rate. What is the straight line rate? It's the 257 five times 0.25 So so that's going to give us the 64 3 75 So that means the straight line rate is 25 percent in this case Which makes sense because it's four years 25 a year is how much we're going to depreciate over the useful life of four years Now that we have that and we say that we're going to say, all right Well, then we're going to use the double declining method Therefore we're going to multiply times two in order to double the rate so that we can then be on the double declining method Therefore if we multiply that out, it's going to equal the 25 percent times two Which of course will be The 50 percent so the double decline rate will be 50 percent. Why because the straight line rates 25 Therefore we're going to double it and get to 50 percent now that we've done that in a very long way I'm going to show you kind of a shortcut to do that and get the double decline rate in a quicker way Uh, in order to do that we would start off with basically, uh, just one I'm just going to start off with one and then divide it by the number of that number of years happens to be four in this case It's going to be a useful life of four years number of years for the useful life And this calculation will give us the straight line rate So i'm going to say this equals the one the one over four the one fourth gives us that 25 percent Once again, it's a percent because the cell is formatted in the home tab Numbers group as a percent and that gives us the same 25 percent So we can calculate that in these two ways. It's kind of the quick way to calculate it Uh, in order to get that 25 percent then of course, what are we going to do? We're going to double it Therefore we're going to multiply it times two And that will give us our double decline rate. So it's going to be the 25 percent times two There you go, and we have that information there now If you wanted to go back and clean this up and put some underlines in it You could do that by going to the home tab font group and we're going to underline that and then it equals here And then we're going to divide here and we could underline that if we so choose And then we're going to have this times this and then we're going to underline this for the calculation And then the bottom line number you may want to double underline So we could go to the drop down here and say that i'm sorry the drop down here And say that we want a double underline And once again, you could of course do the same type of activity here You would say that we're going to underline here. That's how we got to the 25 25 times two Underline that is how we come down to the 50 Percent which you could double underline and say that's the bottom line number So there's a different kinds of formats you could