Moderated by Emily, Digital Transformation Consultant at Hyperbots
Emily: Hi, everyone. This is Emily and I’m a digital transformation consultant at hyperbots Inc. Today I’m very happy to have John on the call with me, who is the VP of FP&A, at XR Extreme Reach. So thank you so much, John, for joining us.
John Silverstein: No problem.
Emily: The topic we’d be discussing today is GL codes and debit or credit entries for vendor invoices, and I’d want to kick it off by asking the 1st question, which is John, can you explain what happens in the general ledger when a vendor invoice with multiple items is posted?
John Silverstein: Yeah, when a vendor invoice has multiple items, the GL, looks at those items based on their classification and where they should go from both a tax accounting account basis, department even, and those types of things. So it will go in and classify everything correctly based on the item code. So it’s not by the invoice or customer. That’s 1 thing to note because some people get confused when you look at one account of items, some items on the same invoice might go to tax lines versus office furniture versus computer equipment. So one example is that, like you get a. you have 2 items, office furniture, and computer equipment. One for the office furniture is $10,000. Your computer’s equipment is $5,000. Each of these items would be subject to different tax rates potentially and item, one would have a sales tax rate of 5%. The county tax sales of 2% item, 2 might have 6% and one and a half percent. The total invoice amount before the tax is $15,000. Then you will get office furniture. The item code will go to office furniture and to the account code for office furniture, and if it’s over your limits and everything, then it will capitalize that versus hitting your expense directly. And you’ll have that $10,000 with the $500 of sales, tax, and county tax 200 for a total of 700 hit the tax lines and then your computer equipment of 5,000, and the 6% 375 for 375 of taxes. So that’s it, will Calc directly based on those item codes. So it’s important to get those right.
Emily: Got it understood. So, John, what are the specific debit and credit entries that need to be recorded in order for you to know such, let me just do that again. So, John, what debit and credit entries need to be recorded in the GL for such an invoice?
John Silverstein: Yeah, for such an invoice. You need to debit entries. You’re gonna have furniture and fixtures because you’re creating those assets for $10,000, which would be a numbered code ideally, too, with maybe 1 5 0 0 as the account number and it will record that office furniture as an asset for the computer equipment. It’s over $5,000. So if that’s your threshold and things, too, it will record and purchase the computer and debit the computer equipment as an asset as well. Sales tax payable. We’ll debit $800 and the county sales tax debit 275 as well on the payable side, and then your credit entries would be the accounts payable for 16,075, which includes the full amount, plus the taxes.
Emily: Got it understood. So, John, why are these specific GL codes chosen? And what do they represent in the context of financial reporting?
John Silverstein: Yeah. So these GL codes are chosen based on the nature of the transaction. So because the item is furniture and fixtures, you’re going to hit that GL code 1,500, which represents the capital expenditures for office furniture. So by debiting this account, we can increase the value of our fixed assets on the balance sheet, and you would set up the schedule, too, for amortization as well. That we’ll talk about in another episode, I guess, or in conversation. But computer equipment assets would be 1 5, 1 0 similar to above. This code represents the capital expenditure for computer equipment. It debits and increases that fixed asset as well. So you can start amortizing, appropriately based on what that code amortization is. So if it’s 1 year, 3 years, 5 years, those types of things you can. It will also pick, based on the code that you put State sales, tax payable. These codes represent the liabilities for sales tax owed to the State and county tax authorities respectively. So you’ll debit these accounts temporarily reflecting the recognition of the tax liability until the payment is made and accounts payable. Same sort of thing, a liability account representing the total amount. the choice of these gl codes. It ensures proper classification and accurate financial reporting of these items.
Emily: Understood, understood, and just out of curiosity. How would the entries differ if this invoice was, let’s say, for operational expenses instead of capital items?
John Silverstein: Yeah. The main difference is that it would go directly to your expense. So it is generally a 6,200, 6,300, or whatever your numbering system is for the P. And L. Accounts. So you would hit office supplies and hit the $10,000 as an expense, and then the IT services. Would be $5,000. As well. So you would. It’s 2 different accounts, and your sales tax, though, would remain the same, and you would have to have the office supplies expense and its services, and then the State sales, tax payables, and county sales tax payables.
Emily: Got it. So, John, what challenges do organizations face when posting invoices with multiple items and varying tax rates? And how can they address these challenges?
John Silverstein: Yeah. So to address these challenges and to make sure that when you’re posting the invoices with multiple items of varying tax rates is making sure that you have matching tax rates. So different items may have different tax rates depending on the jurisdiction. It may even be if it’s a resale item, too. You have to. There are other rules in there, too, that you might be exempt from, so it can check those types of things as well. It also, if you’re paying the taxes versus itself tax versus, you’re paying the tax directly to the vendor, those are different coatings as well, so you have to make sure that you get all those correct. So complexity and matching tax rates are critical and it’s complex, particularly in the US. It’s by jurisdiction. Multiple GL codes also complicate the data entry, since it’s not just, that you don’t just purchase one item at a time in one invoice. That’s many items. So those have all different rules depending on it can be services and potentially items that you’re doing. And then they have different tax rates to address these challenges, too. You need to. You can use AI and machine learning to classify these invoice items, apply the correct rates, and make sure that it does capitalize when it’s supposed to be capitalized versus going to the expense rate which would also affect your income tax basis. So integrate with the tax engines for those jurisdictions. You can also have the validation checks. and that will ensure that you have accurate financials.
Emily: I’m doing one last question to summarize everything. John. Now that you mentioned AI and Ml, right, how can technology, particularly AI help in improving the accuracy and efficiency of gl entries for vendor invoices?
John Silverstein: AI can significantly enhance the accuracy of the Geo entries because you can have that data extracted from the invoice and make sure that you’re capturing. It has both items, codes, items, descriptions, all those things that can really check and make sure that you’re actively getting it through the Ocr. You can also use natural language processing techniques to reduce any manual data entry errors. You can also do smart classifications based on the AI models that can classify each item of the invoice to correct gl codes, so you can have it. Go through and look at the historical data plus predefined rules, and you can ensure that those items correctly classify the tax calculations with compliance. AI can automate the application of the correct tax rates and make sure that you’re applying those correctly as well. You also have detection of anomalies, that is, if there are unusual patterns or discrepancies in the invoice, AI can pick those up and alert the finance team for an extra review that can obviously enhance the quality of our financials and make sure that we’re accurately stating everything and get it can also speed up our time.
Emily: got it. Thank you so much. John, for being here with us and talking to us about GL codes and debit or credit entries for vendor invoices. It was really great having you, and the discussion was really insightful. So thank you so much.
John Silverstein: Great great to be here.
Moderated by Kate, Financial Technology Consultant at Hyperbots
Kate: Hi, Jon, thank you so much for joining us today. So let’s just dive right into the questions. So coming to the 1st question, why are segments like company code cost center code project code and important in a chart?
Jon Naseath: Absolutely It really comes down to if you want to be able to see and if you’re thinking about your general ledger, then you have the. You can look at things as to how the company looks. How does this entity look? What’s this? Does cost center profitability as an example? And then you mentioned Project Code and Gl codes and others. I would. I would argue that company code. Certainly, you need to be able to see what is the full P and L. View, or at least what is the financials for that company. Also for the cost center. You know what’s the cost and expenses specifically to that department, or mark such as marketing, or it to help drive performance project code. It depends. It has, I would argue, it should be a large project, like a major initiative that you’re doing or a major development effort where you do need to have that project full P. And L. Because it’s a lot of work to maintain and to integrate that into your system? And then just the gl is what ties all those together across assets and liabilities and enables that full view across the different, all the business units that you’re talking about.
Kate: Okay, that’s understandable. Moving on to the second question, what are some best practices for naming conventions for these segments? And why standardization? Important.
Jon Naseath: Yeah, there, there’s just I’ll call them standard ways, like, as you said, default ways of being consistent is the main thing and making it. So that when somebody’s looking at these codes, they understand and kind of interpret what you’re talking about. So with company code as an example.Understanding as part of that you think about what is the syntax within the code. So it might be that there’s a country at the beginning like us, dot 0 0 1 could be. The country could be a company code for a US Entity. A cost center could be, you know you might put some letters that represent an example like Mkt. 0 0, 1 could be marketing. What do you want it to be able to be something, so that a human can interpret what these codes are doing in a sequential order of, you know, revenue and different departments can also be helpful? And then, when you’re doing a project code as an example, something that it’s again, I would suggest a major initiative you’re doing. But you want to be clear that these are the costs that relate to it for a given year. You might say this is Project Code Xyz, or whatever. But then put 24 at the end, like the year. Something represents what year it’s for so that you’re looking at your costs for a given period. It’s very clear how to distinguish. Even if it’s a major initiative program. You want to know that these are the costs for one year versus the next year in that example. I’ve used that before. But just consistency is the key thing and you know it should be easy enough to interpret how those codes are gonna map to. If you think about your management reporting aspects of summary of management reporting, and what periods they go to, and things like that.
Kate: Okay, yeah, I agree with you. So moving on, what are some common mistakes accountants make with these segments, and how can they be avoided?
Jon Naseath: Okay one example is they people are putting the wrong transaction to the wrong code. So misclassification of codes.And then if you do that. You know the thing that accountants hate is having to do reclassifications, because, you know, if you get an auditor coming in and say, Oh, that was done wrong, and then you have to later reclassify something. Whether that was because it was a mistake or because the business changed, and maybe the timing of how things were coded wasn’t accurate in time but having to do reclassifications is always painful and then redoing, and oftentimes if you’re in a big public company, you’ve reported numbers. You just don’t want to do that. It can create big problems for investors with redundant codes. So seeing that there’s actually something you can have. I like to call it blowing out your chart of accounts where you just have too many codes and reality is the accountant who’s trying to map things to the code. There’s no difference between A B or C from their point of view, or maybe the transaction would apply to all of them, so they’ll usually just pick one and then you end up having 2 other codes in that example that just aren’t used. So that’s if you’ve blown out your P. And L your chart accounts too much, then it’s kind of a waste of time. Also inconsistent coding. So if you have, say that I was describing some of the syntax before. if you use 3 letters, and then a number, or if you use 3 numbers a dash, then a number. You know, you just want to be consistent. So it’s clean and that’s hard over time. Things change. But doing the classic example in this is it? I’ve seen companies. I’ve been involved in companies where previously they had put all of their products into the chart of accounts into the GL and that might be good intent at the beginning when you only have a few products. But then they have, like dozens and dozens of products. Every time the product wants to reshuffle how they’re presenting their products you would need to update your chart of accounts to map to that. So I’ve seen problems from that before because you don’t remove the historical accounts. You just add new ones to it, if it’s problematic.
Kate: Couldn’t agree more, moving forward. How can organizations maintain the integrity of these segments in their ERP systems?
Jon Naseath: Yeah, it really comes down to data governance so you need to have consistency and integrity of the chart of account segments. I think one of the best ways of doing that is, having an owner, you know, having role-based access controls, controlling, who has authority to update that oftentimes that comes down to the job of the controller and that’s kind of one of the main jobs. The controller by definition is to control which accounts are going to be called what things, and try to maintain some consistency even though the business is changing and enabled. So you can do historical reporting on the new views but just define the standardized naming conventions doing regular audits and making sure that things are consistently showing up. I mentioned in a previous discussion about the budget to actual reconciliation. So if you’re doing a budget or a forecast, and how those map to your chart of accounts that will flag if your forecast, where you’re gonna look at the business is consistent with your I’ll call it historical way of looking at the business in your chart of accounts. So just doing those budget versus actual reconciliations is helpful and then automating validation rules. So that as you’re entering entries into the system they’re coded correctly and there are different reconciliations, and controls you can put in place in most ERPs.
Kate: That was really insightful. I totally agree with you. Moving forward with the next question, what role does technology play in managing these segments effectively?
Jon Naseath: Yeah, I describe the main role as helping flag or raise inconsistencies for you to be able to see them, and either preventative controls or detective controls right? It’s gonna prevent you from coding it incorrectly upfront or if you’re on the FP and a side, and you’re seeing inconsistencies, it can flag things for you that you can then work with the accountant to clean up so automated detection. It may help generate the codes automatically based on whatever the transaction was, it can suggest different codes for you, for the Gl or the call center. you know, just there’s a lot of times of manual errors that can happen, and it can help prevent those as you’re coding things. Data integrity. Again, the ERP system looks for duplicates, looking for missing values, or something that was hard coded wrong, and then dashboards again. It’s always funny to me, cause the situation is when you have, like a senior executive that really wants to see the real-time accounting dashboards of what’s happening but with accounting you’re always in the process of trying to catch up and you know, book the transactions at one of the companies I’m working with right now. The accountant got pulled into something else, and he’s 3 months behind in booking the accounting. It’s a smaller company, but the executive wants to see his dashboards, and the numbers are just wildly off, so if management’s making decisions based on these historical numbers that are wildly off that’s problematic. So technology can help keep you consistent and help book things in real-time as they’re happening. So that you’re just kind of managing by exception as opposed to having to book everything manually.
Kate: Understood. So we have almost reached the end of our interview. Can you provide examples of how errors in segment coding can impact financial reporting?
Jon Naseath: You know well, not only I’ll call it not only impact the financial reporting, but impact your whole business like if you’re in a public company, and you’re coding something to the wrong place. Then you report those numbers. Investors make bad decisions, and usually, then lawsuits can happen because they’re like, oh, that was intentionally misstated and we made investment decisions based on whatever. So I remember just kind of this tight schedule of closing the books, and then rushing to get all the books closed, and then at the month end, accounting financial preparation done. So you can produce investor analyst reports for a public company and there was this army of like 30 or 40 investor analysts just waiting to dive in and find any anomalies in what you just reported and I remember just once or twice. I don’t remember if it actually happened, but I remember the fear was always like, if we miss something, then they’re gonna call you on it because it’s wrong. You have to say, oh, that was an error, that’s just bad for the team. So we avoided making errors but you end up with misstated financial statements. You have compliance issues that auditors would find and an inaccurate profitability analysis, like, what is the profit? What is the forecast? What’s your guidance going to be for the next quarter that you’re gonna give? All those are off? If your core things have been coded incorrectly.
Kate: So the last question for today, what steps would you recommend to an organization looking to improve its COA segment management?
Jon Naseath: Yeah, the 1st thing that I’d call out is verifying the historical accuracy and knowing what numbers you can rely on, I’ve been in a situation where a company hadn’t had proper controls around their accounting historically when I was brought in, and we tried, and previous to my joining the owners had made different business decisions based on well, they frankly they bought the company that I was then brought in to help them manage, based on these inaccurate accounting numbers. And so then, when I came in and figured out what actually was happening, and why they didn’t have enough cash at the end of each month. It was because of these basic accounting errors which I’ll say could have been avoided. So you know, just implementing standard close process standard controls in place naming conventions around what codes need to be what? And making sure that they’re coded correctly and used consistently. Leveraging technology, I’d call out specifically AI nowadays a lot of the ERP systems, you know, when I started my career, different ERP systems were different Oracle sap like QuickBooks.They all kind of competed on feature functionality but nowadays they’re also similar in their core functionality. So there are other tools that can help leverage. What’s there get your clothes faster, better, cheaper, and less costly. Regular training, making sure that the team, and specifically, I’ll call it business rules, make sure that your different team has the same business rules that they’re following when they’re coding things. Usually, I’ll have like. if there’s an accounts payable clerk, there’s a 1 page, something that they use as guidance to know how to code, what, and where. As an example and then putting in place the appropriate review mechanisms. As I mentioned before. if you’re in a big public company and your numbers are going to. Investors are making investor decisions in real-time. You have a series of reviews and a series of controls in place literally, like number by number, checking and automated, checking, manual checking, and having a binder for each close to show what you checked and that you signed off on everything. Just those are standard things when you’re doing accounting closes for big public companies. But I’d argue what I spent a lot of my subsequent career doing is implementing those similar sorts of controls for smaller companies that aren’t big in public because someday they might be, and regardless of whether you’re public or you have investors looking at your numbers every day you, should you? You want to have clean numbers so that your management can make good decisions and grow the business. So consistency completeness, accuracy, all your classic accounting things that auditors will look for later. Make sure those controls are in place. Don’t rely on just your auditors telling you when you should fix things, get them clean so that your management can make good decisions from the start.
Kate: So much, Jon. That was a really insightful conversation. Thank you so much for your insights. It was really nice to have you today with us here and thanks a lot. Have a nice day.
Jon Naseath: You, too, have a great day. Thanks.
Moderated by Sherry, Financial Technology Consultant at Hyperbots
Sherry: Hello, and welcome to all of you on CFO Insight. I am Sherry, a financial technology consultant at Hyperbots and I’m very excited to have Jon Naseath here with me. He is an accomplished executive with expertise in AI, machine learning, and computer vision driving impactful technology solutions in education, healthcare, and business. Thank you so much for joining us today, Jon. Our discussion will focus on the differences, similarities, and reasons for variations in the chart of accounts across different ERP systems. Let’s dive right into it. Can you briefly explain what a chart of accounts is, and its importance in financial management?
Jon Naseath: Sure. So I approach the chart of accounts a little differently than others might because I have a background in information systems. And so, from my perspective, the chart of accounts is kind of like a master data table that defines a standard structure that you’re gonna use for how you want to manage your business. In the simplest way of thinking about it, it’s a listing of the most detailed level that includes all P&L records, like the drill down to the P&L at the base level, and then also it includes the drill down for the balance sheet at its base level. So, it includes all of them. And then from there, you’re going to have other tables that will have accounts receivable and accounts payable and other sub-ledgers they’re called, so a general ledger chart of accounts sub-ledger. This chart of accounts is the master data that you use to structure how you’re gonna roll everything up to the P&L and balance sheet. Just one more piece there. So if it’s the most detailed level down, then you might have like these five types of revenue, and then you’ll roll them up to be your revenue number in a financial statement as an example, or whatever the summary numbers are you see in your management reporting. The core foundation of those financial statements is your chart of accounts.
Sherry: And in your experience, how would you say the chart of accounts is structured differently across the five ERP systems like Sage Intacct, QuickBooks Online, Dynamics, SAP Hana, and NetSuite?
Jon Naseath: The way I would describe it is that each of those companies has a default out-of-the-box chart of accounts that they’ll present to you as a potential customer using their product. Each of them has different target markets. QuickBooks and Sage Intacct are focusing on one business entity at a time, so they want to present a relatively simple chart of accounts, while SAP Hana, Dynamics, and NetSuite want to present that they have flexibility and can handle more complex businesses and dimensions. The reality, though, is with rare exceptions, I’ve ever seen a company who can just adopt whatever is the chart of accounts from any of those systems and then adopt it going forward. Usually, there’s some level of customization that’s required anyway, so the systems are just saying, “What’s the best way we can give a starting point for that customization?”
Sherry: And why would you say ERP systems like SAP Hana and Dynamics have more detailed and segmented GL codes compared to others like QuickBooks Online?
Jon Naseath: The reason I’m pausing is that from my perspective and a pure database design perspective, they’re not different. It’s just designed for how you need to support the customer. They’re still going to be your revenue, the numbers that apply to your business. There are systems designed to support businesses that have different parts of dimensions for each data center, for example. So, it comes down to what are the different ways that you want to slice and dice the chart of accounts. What slicing and dicing dimensions are you going to build into your chart of accounts codes versus other sub-ledgers outside your general ledger chart of accounts?
Sherry: And how do localization requirements affect the chart of account structures in different ERPs? Could you provide an example?
Jon Naseath: Yeah. So, like NetSuite and SAP Hana, oftentimes they’re designed to support global operations. There might be different tax codes, GAAP rules, and IFRS rules, and you’ll design your chart of accounts to support those roll-ups. For example, QuickBooks might focus more on the U.S. market and try to present a simplified structure, while global organizations would require more complexity to consolidate their financials. Without systems that can handle this complexity, you might end up doing roll-ups manually in Excel, which can be painful.
Sherry: As you touched upon customization in ERP systems, what role does customization play in determining the differences in the chart of accounts across these ERP systems?
Jon Naseath: Two quick examples come to mind. I was working with a company where their new finance leader got them to switch from NetSuite to QuickBooks. However, they soon ran into complexities, such as a lack of flexibility for different locations and vendors. They ended up mapping dimensions manually, creating what I like to describe as a “bloated” chart of accounts. The worst case is when companies put all their products as different codes in the chart of accounts. Initially, the accounting team thinks it’s great, but months later, they’re just tagging stuff to the simplest codes, and many codes remain unused.
Sherry: Can you also discuss the similarities in the chart of account structures across these ERPs, and why these similarities are important?
Jon Naseath: At the end of the day, it’s about the P&L and the balance sheet. You’re talking about revenue, cost of goods sold, gross margin, and operating costs. These core elements of the financials are what you need your chart of accounts to support. The beauty of a chart of accounts is that it includes both the P&L and balance sheet, ensuring that adjustments are reflected consistently across both when you understand the system, it’s pretty straightforward. It’s just another master data table in your database that defines how you run the operations of your business.
Sherry: Could you provide a specific example of how a particular industry might benefit from the unique chart of account features of an ERP like SAP Hana or Dynamics?
Jon Naseath: SAP Hana is known for inventory management. It allows businesses to track costs per revenue, per product line, per region, and business unit. For global companies with complex operations, this level of granularity is essential for understanding profitability across multiple dimensions. Dynamics has similar capabilities, allowing for multi-dimensional analysis without overly complicating the system.
Sherry: And why might a smaller company prefer an ERP like QuickBooks Online or Sage Intacct over SAP Hana or NetSuite?
Jon Naseath: A smaller company might prefer QuickBooks or Sage Intacct because they offer straightforward solutions. When your business operations are simple, these systems have all the features and functionality you need without the complexity of larger ERP systems. When businesses get more complicated, they might outgrow these systems and need to upgrade to something like NetSuite or SA then you need other plug-on tools. I have another. Just no, he wants your questions. I have some other thoughts, but we’ll see if your questions bring him up. Go ahead.
Sherry: And how do integration needs impact the differences in the chart of accounts across these ERPs? And can you provide an example for the same?
Jon Naseath: Okay. Now, that wasn’t planned. But that was the next thing I was gonna bring up. So that’s cool. Oftentimes, when you’re talking about ERP systems, it’s kind of this catch-22 because you have your accounting team that wants the data from throughout the business. Maybe 10 years ago, the plan was, well, let’s get everyone Oracle licenses within accounts payable. Let’s get everyone, whatever. Even different business leaders outside of accounting finance needed to have access to that ERP system, and I’m sure ERP sales reps want that to be the case. But I think this somewhat fell apart when the ERP system started buying other integration systems. So now you have your HR system, your expense management system, and other tools, which bluntly, have a little bit nicer user interface, ease of use, and maybe apps that are cool, focused on specific business roles.Those systems, which back in the day, we used to custom-build just so people would use them, because there’s nothing worse than making someone log in, click multiple times, and then finally get to what they need. So give them what they need with a simple user interface. But then, that can feed straight into the general ledger, chart of accounts where needed, or sub-ledger, ensuring it’s coded correctly and avoiding errors.
Sherry: And looking forward, how do you see the differences in the chart of accounts across ERPs evolving as businesses continue to grow and adopt new technology?
Jon Naseath: You know, a lot of the challenge I’m seeing is businesses are evolving quickly. Their business models are evolving quickly. They’re doing M&A, adding new revenue lines, cutting costs, or adding new divisions. Every time you make that fundamental change to a business, in theory, your chart of accounts should update or align to support that. But often, it doesn’t, so you end up creating a new account code, tagging everything to it, and leaving the old ones behind. This results in the chart of accounts being out of sync and not applicable. Technology can help here because, typically, finance ends up creating a mapping of the chart of accounts in a spreadsheet to management reporting needs, along with allocation logic for dividing costs among departments or divisions. And while that’s fine, it’s manual. What AI and technology can now do is help automate this mapping. Based on historical mapping data, AI can generate management reporting and reduce errors caused by manual processes. A lot of manual mapping, revenue discrepancies, and errors in cell linking or extracting data into reporting tools can now be simplified. AI can even map transactions to reporting directly, bypassing the GL in some cases. The GL, being a summary view, still needs reconciliation to sub-ledgers and other systems. AI can help make this process faster and more accurate by automating checks across systems. So, closing the books could become much faster as AI ties the sub-ledger directly to the GL, ensuring it’s complete and accurate.
Sherry: Thank you so much for these insights, Jon. It’s clear from this conversation that the differences in charts across ERPs are shaped by a variety of factors from the size and complexity of the business to the need for localization, customization, and integration. This conversation has been incredibly informative for understanding how businesses can choose the right ERP for their financial management needs.
Jon Naseath: My pleasure.
Moderated by Emily, Digital Transformation Consultant at Hyperbots
Emily: Hey, everyone, this is Emily, and I am a digital transformation consultant at Hyperbots. I’m very pleased to have Anthony on the call with me. Anthony is the CEO at Coast to Coast Finance. Thank you so much for joining us today, Anthony. We appreciate it.
Anthony Peltier: Thanks, Emily.
Emily: Today, we’ll discuss the intricacies of handling multi-currency purchases. Let’s just dive in. Anthony, multi-currency transactions are a common challenge for companies operating globally. Could you walk us through the typical scenarios where a company might face multi-currency purchase challenges?
Anthony Peltier: Yeah, definitely. As you mentioned, when a company operates globally, they may deal with vendors who typically prefer payments in their local currency. Several scenarios can arise, right? Whether you’re receiving quotes in a foreign currency, sourcing items from multiple countries, or generating global purchase orders, it’s important to think about how to manage the PO, how to handle payments, and how to record currencies in your general ledger to mitigate risks due to currency fluctuations.
Emily: Got it. When a U.S-based company deals with, let’s say, European vendors who prefer payments in Euros or GBP, how should the company decide on the currency for purchase orders and payments?
Anthony Peltier: Good question. Generally, I would recommend issuing the PO in the vendor’s preferred currency. That way, you can provide clarity on pricing and avoid complications due to rate fluctuations. Then you can make the payment in the currency specified in the PO. Of course, the company’s GL would still record the transactions in their functional currency, whether that’s USD, Euro, or whatever is standard for them. This approach balances the need for vendor payments with internal financial accuracy.
Emily: Understood. In situations where vendors provide quotes only in foreign currencies, how should a company handle this when issuing the purchase order and recording the transactions in their general ledger?
Anthony Peltier: Right. When you receive a quote in a foreign currency, the PO should reflect that currency to ensure the vendor receives the expected amount without conversion risks. Then your GL would record the PO’s value in your company’s functional currency based on an exchange rate that you’ve set up, perhaps in your ERP for currency conversion. If there are fluctuations in the rate between the PO date and the payment date, you may capture that as a purchase price variance, or if this occurs frequently, you may set up a forex gains and losses account.
Emily: Got it. Companies often source components from OEM vendors located in different countries. How does multi-currency management come into play in such scenarios?
Anthony Peltier: If you’re issuing multiple POs and managing multiple currencies, I would say issue the PO in the vendor’s preferred currency and make the payment accordingly. Your GL will convert and record these transactions in your functional currency. The real challenge lies in managing multiple exchange rates and understanding how fluctuations can impact overall costs. In such cases, having robust controls in place to track and manage these variations is essential.
Emily: Understood. That makes sense. For multinational companies with operations in various countries, how should they handle global purchase orders and the associated currency risks?
Anthony Peltier: For multinational companies, can issue the PO in either the local currency or the vendor’s preferred currency. You’ll want to record it in the local GL for the respective country where the company is operating. The parent company can then consolidate these local GLs into a global reporting currency, whether that’s USD or another currency. This allows each regional operation to manage currency risk locally while enabling the parent company to assess overall exposure and performance on a global scale.
Emily: Got it. That makes complete sense. Anthony, forex gains and losses are an inevitable part of currency transactions. How should they be computed and posted in the GL?
Anthony Peltier: If currency exchanges happen frequently, forex gains and losses are inevitable. For instance, if you issue a PO in euros and the exchange rate is 1 = $1 at the time, but when the payment is made, it’s 1 = $1.20, that additional cost would be recorded as a forex loss in the GL. Conversely, if there’s a favorable price shift, you’d record that as a gain.
Emily: Understood. How exactly can companies protect themselves from significant forex fluctuations when dealing with multi-currency purchases?
Anthony Peltier: That’s a good question. You can use hedging strategies or contracts to lock in exchange rates. Beyond purchases and vendor management, global companies must also consider how they pay employees in different currencies. If a parent company monitors forex markets, they can buy the currency needed for payments in advance to lock in favorable rates. The key is balancing risk management with cost efficiency, ensuring that hedging provides more benefits than costs.
Emily: Makes sense. Just to summarise, one last question: What role does AI, or what role potentially can AI, play in managing multi-currency transactions effectively?
Anthony Peltier: AI can be a game-changer. Automating exchange rate calculations and integrating real-time currency monitoring into your systems can make a big difference. The next step is to fully integrate this into your ERP to manage multi-currency POs, material requirements planning, payments, and GL entries. AI can also reduce manual errors. For example, someone might mistakenly move a decimal, leading to significant discrepancies. A quick story long ago when I first started working, I got a letter from the IRS saying I owed a substantial amount in taxes. It was a significant sum for me at the time, but it turned out they had moved a decimal point by mistake, leading to confusion. With AI, you can reduce such errors, predict currency movements, and make more informed decisions about currency conversion.
Emily: Got it. Thank you so much, Anthony, for joining us today and sharing your insights. Handling multi-currency purchases requires a strategic approach, combining financial acumen with the right tools and processes. Thank you for shedding light on this topic.
Anthony Peltier: Absolutely. Managing those transactions effectively is crucial not just for financial stability but also for supporting business operations on a global level, right?
Emily: Alright.Thank you.
