Chart of Accounts(COA) and GL coding in Microsoft Dynamics

Find out interesting insights with Claudia Mejia, Managing director at Ikigai Edge

Moderated by Emily, Digital Transformation Consultant at Hyperbots

Don’t want to watch a video? Read the interview transcript below.

Emily: Hi everyone, this is Emily, a digital transformation consultant at Hyperbots, Inc. I’m happy to have Claudia Mejia, managing director at Ikigai Edge, with us again. Thank you, Claudia, for joining us.

Claudia Mejia: I am happy to be with you.

Emily: The topic today is a chart of accounts and GL coding in Microsoft Dynamics. For a small but growing business, what are some key considerations when setting up a chart of accounts in Microsoft Dynamics?

Claudia Mejia: One of the beauties of Microsoft Dynamics is its multidimensional capabilities. This allows you to set up different dimensions like departments, call centers, regions, eliminating the need to create multiple GL accounts for every dimension combination.

Emily: So, Claudia, how can businesses leverage Microsoft Dynamics features to maintain an effective chart of accounts as they scale up?

Claudia Mejia: When designing the chart of accounts, they should definitely define the dimensions that meet their needs. By using dimensions, you can match transactions to specific departments, product lines, geographical locations, or business units. You can also use advanced rules to automatically allocate expenses to specific multi-dimensions and GL accounts. Additionally, you can configure your account structure to define which financial dimensions go with each account.

Emily: Got it. That was insightful. What are some common mistakes businesses make when setting up their chart of accounts in Microsoft Dynamics, and how can they avoid them?

Claudia Mejia: Businesses coming from a small business system to Microsoft Dynamics tend to create GL accounts for every combination, which can be complex and time-consuming. To avoid this, ensure you design financial dimensions and use them properly. Additionally, leverage the chart of accounts designer tool to ensure you use the right combinations and avoid future issues when allocating expenses.

Emily: Understood. So, how can businesses create a flexible and scalable chart of account structure that maximizes Microsoft Dynamics capabilities?

Claudia Mejia: There are four functionalities to consider: defining dimensions, using account structures and their combinations, using rules to ensure expenses go to the right accounts, and using the chart of accounts designer to be proactive in how you use these combinations. Many small businesses don’t utilize these capabilities to their full potential. So, study the functionalities and establish a process for setting up these structures.

Emily: Got it. How can businesses leverage AI capabilities outside of Microsoft Dynamics to maintain a chart of accounts integrity?

Claudia Mejia: My preference would be an AI platform that connects via API to the system. This way, AI can read transactions, ensure they are allocated to the proper accounts, and perform predictive analytics to automate certain compliance tasks. Platforms like Hyperbots can do this in one solution. There are also other solutions for specific tasks, like AI for automatic account reconciliation or machine learning tools to identify duplicate entries. However, my favorite would be a solution that can automatically integrate into the system.

Emily: Got it. Got it. Can you provide an example of how Microsoft Dynamics financial dimensions can reduce complexity in the chart of accounts?

Claudia Mejia: Let’s say you want to track travel expenses for a department and a project. You can set up dimensions for department and project. Instead of creating GL combinations for marketing and project A or marketing and project B, you can simply create the dimensions and automate rules to ensure specific vendors and transactions go to the designated dimension and GL account.

Emily: Got it. Understood. One last question. How can AI facilitate migrating from Microsoft Dynamics to another ERP or consolidate multiple Dynamics instances?

Claudia Mejia: AI can read the context of GL account descriptions. If you have two Dynamics instances to consolidate, an AI tool can identify and map the corresponding GL accounts to avoid duplication and recommend how to do it. This, combined with a data migration framework in Microsoft Dynamics, can significantly improve efficiency by eliminating manual mapping. AI can reduce errors and ensure compliance, leading to sound financial reporting. Matching accounts properly is crucial.

Emily: Got it. Thank you so much, Claudia, for these insightful answers on managing and scaling the chart of accounts in Microsoft Dynamics. It was great having you, as always.

Claudia Mejia: Oh, thank you, Emily. Great talking to you.

Impact of GL Coding on financial reporting and audits

Find out interesting insights with John Silverstein, VP of FP&A at Extreme Reach

Moderated by Emily, Digital transformation consultant at Hyperbots

Don’t want to watch a video? Read the interview transcript below.

Emily: Hi, everyone. This is Emily. I’m a digital transformation consultant at Hyperbot Sync, and I’m pleased to have John, who is the VP of FP&A at Extreme Reach, on the call with me. So thank you so much for joining us today, John, really appreciate it.

John Silverstein: No problem. Thank you for having me.

Emily: Of course. So, John, the topic that we’d be discussing today is the impact of GL coding on financial reporting and auditing and I want to begin things by asking why GL coding is so important for financial reporting and auditing.

John Silverstein: Yeah, GL coding is critical for your financial reporting and audit, otherwise it becomes very difficult to report correctly, and you have to go to the transaction level, and then it defeats the purpose of the GLs. So it’s critical. It’s also extremely hard to audit something when it’s mixed, and you’re also generally not compliant if you’re not coding things properly in the financials. So it is critical both from a reporting and audit perspective and also for management to make proper decisions and everything to make sure that selling and marketing expenses are selling and marketing expenses and then it’s easily tracked. And you know who the owners are, and you know what it is.

Emily: Got it. So let me ask you this, how does a well-structured GL coding scheme enhance decision-making for the management?

John Silverstein: Yeah, if you well structure the GL coding, the decision-making, you have to align your GL coding to not only align from an accounting and GAAP standpoint, but also to make sure that you can make proper decisions on pricing or do proper ratios and things like that based on how you break your financials out. GL coding allows you to get segment reporting and figure out how profitable certain areas, products, or service lines are. If you don’t break it out and you don’t have the right granularity, it gets complicated to figure out the important information to make decisions in the business.

Emily: Got it. So just out of curiosity, John, can you provide an example of how GL coding affects compliance with regulatory and tax requirements?

John Silverstein: Yeah, GL coding is critical. If your transactions aren’t accurately classified with GAAP, it can affect your tax calculations, anything from sales tax to VAT to corporate income tax. You can end up overpaying or facing audit issues on the tax side as well. You must follow proper accounting, have the right GL coding, and minimize penalties for noncompliance. If VAT is consistently coded under a specific GL account, it becomes much easier to prepare accurate VAT returns and comply with local tax authorities.

Emily: Got it. So what are some of the common mistakes that organizations make with their GL coding schemes, and how can they be avoided?

John Silverstein: The biggest mistake is over-complication of the GL, where you start making GL codes for everything. But then there’s the opposite side, where you don’t break things out at all, and it’s all lump amounts, which makes decision-making hard. It’s critical to find a balance between detail and summary-level data. Make sure you have proper hierarchies so you can go more granular if needed and have a proper roll-up. There are also tools now that help with different ways of reporting from a management perspective that can help this as well.

Emily: Understood. Also, John, how can a GL coding scheme be designed to provide real-time or near-real-time financial reporting?

John Silverstein: If your GL coding is proper, then as transactions are happening in your GL, ERP, or even CRM, you can see that data at the right levels in near real-time. This allows you to see where you might end up from a financial standpoint and make decisions like ramping up production or slowing down sales based on live data. It’s important to align GL coding with ERP, CRM, and procurement systems to get live financial analysis instead of waiting for month-end close.

Emily: Got it. John, would you provide an example of how GL coding alignment with business strategy can improve performance monitoring?

John Silverstein: Sure. If a company aligns its GL coding schema with key performance indicators, it can monitor and optimize these metrics more effectively. For instance, a SaaS company might use specific GL codes for different components of customer acquisition costs and retention expenses, which gives insights into performance against goals. By doing this, you can generate financial reports focusing on metrics like customer acquisition costs, helping to make more strategic decisions in real time.

Emily: Makes sense. So a little bit about the audit process, John. How does a well-structured GL coding scheme simplify the audit process?

John Silverstein: A well-structured GL coding scheme simplifies the audit process by providing a clear and consistent trail of the transactions. This allows auditors to quickly trace entries, verify accuracy, and ensure compliance with accounting standards. For example, if an organization uses separate GL codes for office supplies at HQ and regional offices, auditors can efficiently sample and analyze expenses related to different locations. However, you need to be careful to ensure your schema isn’t overly complicated.

Emily: Got it. Just to wind things up, one last question, John. What would be your key recommendations for organizations looking to optimize their GL coding scheme?

John Silverstein: First, design a hierarchical structure that goes down to a detailed level but allows summarization. Use multi-dimensional analysis so you can get different insights like company roll-ups, cost centers, departments, and product lines without mixing everything into the GL. Balance granularity and simplicity, and align with the business strategy because strategies evolve. It’s important that GL coding reflects the current business direction. Integrate with other systems like ERP to avoid silos, and regularly review your coding schema to ensure it complies with current regulations and organizational structures.

Emily: Got it. Thank you so much, John, for sharing your insights on the critical role of GL coding in financial reporting, auditing, and decision-making. Your examples and recommendations will certainly help organizations better structure their GL coding schemes to achieve more actionable financial reports. Thank you so much for being here.

John Silverstein: No problem. Glad to be here.

GL coding in the Chart of Accounts(COA)

Find out interesting insights with Jon Naseath, CEO/Founder Cantu Capital Inc

Moderated by Sherry, Financial Technology Consultant at Hyperbots

Don’t want to watch a video? Read the interview transcript below.

Sherry: Hello, and welcome to all our viewers on CFO  Insight. I am Sherry, a financial technology consultant at Hyperbots, and today we are speaking with Jon Naseath, who 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, John. Today we’ll be discussing the importance of GL coding in the chart of accounts, common mistakes companies make, and how technology can help maintain coding integrity. So let’s dive right in. Can you briefly explain what GL coding is, and why it is so important in the chart of accounts?

Jon Naseath: So just briefly, what GL coding is, and I’ll tell you an example of the importance. GL throughout the entire business. People are doing their work. They’re spending money, earning revenue, buying things, or investing in product development. Whatever you’re doing throughout the entire business. That translates into equity. You’re making money for investors or making customers happy. Whatever is your role, there’s a representation of that in the GL. We have to make sure that what you’re doing, what you’re spending, and what revenue you’re making is accurately represented in what’s going to turn out later to be the P&L or your balance sheet. You know, what did we invest in on the balance sheet? And what did we spend, and how much revenue did we make on the P&L? If we don’t map things correctly to the GL, then the rolled-up reporting numbers will be wrong. There are all these very formal GAP accounting rules over how things exactly have to be mapped. The story example I wanted to raise real quick was just a few hours ago. I got an email from a very good friend of mine. I used to work at a large organization, and he’s a leader in that organization. He spends his whole day talking to big companies around the world about how to reduce the cost of IT and cloud spending, and how to help them with strategy. He pinged me and asked me, “Where can I find the right definition of revenue?” I chuckled when I saw that because, I mean, there are people’s whole careers spent helping companies figure out how to define revenue for their business. He asked, “What’s the definition of net revenue?” I spent a year working with a company where there were actually seven definitions of revenue just within that company. They called it gross revenue, sales revenue, RevOps, net revenue, and all these different things. But the reality is, if you ask an accounting person, there’s only one definition of revenue, and there are actual policies around how that’s defined. The reason I bring it up is, that if you’ve mapped all these different things that you do in your business to the GL, and then you map that GL to management reporting, different management reporting people will want to see how what they’re doing impacts revenue in this example. They can make up their definitions, but they should define that there’s one thing that is accounting GAP, you know, audited revenue. All the other stuff is management reporting. If you’ve mapped stuff in wrong, then the core number is wrong. If you map stuff wrong, then the other pieces are wrong. Just bluntly, if you do it intentionally and you’re trying to hide things, people go to jail. So that’s why it matters. But also so investors can understand what they’re doing, and management can have clear views of how they’re managing the business. Long answer to a short question, but it was a pretty loaded question.

Sherry: And in your opinion, what are some common coding schemes that companies should follow when setting up the chart of accounts? Can you provide examples from different industries?

Jon Naseath: Most simply, think about it as your P&L and your balance sheet. As you walk down your P&L, you know, revenue, cost of goods, operating expenses, whatever you have in your P&L. As you walk down your balance sheet, assets, liabilities, etc. All it is is a number that represents walking down your P&L and balance sheet.  The root of your question, though, is within different industries, there’s become quasi-standards around how they’re doing their business. Every company within that industry is also going to try to find its competitive advantage, so they’ll do something unique to them. When they do roll up their P&L and balance sheet, I remember I was in a job where my job was to take that from the accounting team, roll it up into these investor analyst reports, and then we’d hit submit to go live at quarter-end. There was an army of like 60 investor analysts whose whole job seemed to be to find any errors we had in any of those numbers. What they’re doing is mapping that financial statement to other ones in the same industry and seeing if we’re different, wanting to compare them. So to some degree, you want to be similar to your peers in the industry, but for others, you want to innovate. I was at Equinix, which is an innovator in space. We impacted how the industry looks at metrics like FFO and other REIT-related revenues. We made sure we were compliant with revenue. There were lots of things besides just data center buildings that we had as revenue, and we had to account for them correctly.

Sherry: What are some common mistakes you’ve seen companies make with their GL coding structures? Can you provide examples from various industries?

Jon Naseath: One mistake is in the way companies add dimensions to the GL, like region, department, or sales channel. You might see the initial chart of the account code, and then different dimensions get added as “dash something else.” This lets you slice and dice to understand costs by department, region, or product type. But bloating the GL by adding too much detail, like putting all your product SKUs into the chart of accounts, can make it unmanageable. Over time, old codes and new codes can create complications. Another issue is the lack of standardization. It’s important to align with industry standards so reporting can be compared. Insufficient detail is another problem, where management wants specific insights to reduce costs or invest more, but all they have is a generic code for product costs. You need to break things up by what should be capitalized and what should be expensed. Finally, there’s inadequate training and documentation. If people aren’t trained well, they can tag transactions incorrectly, which impacts the rolled-up reporting. That’s why visibility and proper training are key.

Sherry: How do these mistakes impact a company’s financial management and reporting?

Jon Naseath: From a financial perspective, it creates a lot of unnecessary work. Ideally, you could just roll things up and have it reconciled, and everything makes sense. But often, you do plan vs. actuals or month-over-month, and something’s off. You might have a gut feeling that a number isn’t right, and sure enough, you unpack it, find a miscode, and need to reclassify. The impact includes inaccurate or inefficient financial statements, upset executives, and hours of rework. It can lead to compliance risks, resource wastage, and worse, damage a company’s credibility. If a CFO has too many reporting errors, they could lose their job.

Sherry: How do you think technology can help maintain GL coding integrity and reduce these mistakes?

Jon Naseath: Technology is excellent at reconciling across different dimensions and sources. It can tie everything together, but it’s not perfect—AI can sometimes hallucinate. There are automation tools and AI that help, but there needs to be a balance between understanding numbers and producing accurate outputs. For example, I was talking to the controller of a large global organization. They have a complex ERP system and are transitioning to a new version. They’ve gone through the business planning, and they know what they want that future state GL and reporting metrics to look like. And they finish that. But it’s gonna be another at least a year and a half, maybe 2 or 3 years, until they get this full ERP fully implemented, all trained, and are in the new future state system. In the meantime, they’ve got a year and a half and 2 years or more, because things always go wrong in those projects. There’s always some reporting that’s missing, even if they say they go live. It’s never right at first. However, even with what I just said, it’s never right at first. I believe there’s an opportunity here where if you define what you want your future state reporting to look like, and you have that data coming in. And you’ve created this mapping thing that you’re gonna give off to some developers and they’re gonna rebuild the system based on that new mapping tables and then you have to extract the data from the old table, load it into the new table once it’s developed and then wait. Maybe the reports work, but they don’t. And it’s huge UAT testing.  Anyone who’s been through that knows it’s painful. I think AI can do a lot of that stuff. I think you can take from your legacy system, your current system. You can say, here’s what I want my master tables to look like. Here’s what I want my reporting outputs to look like and it can help produce those. Now, again, it’s going to hallucinate. You have to code it the right way to make sure that it gives you the right outputs. But a lot of the pain, which is real pain, or a lot of the late nights because there’s an error, and there’s rework. You have to go through a lot of the cost of hiring an army of people to fix an error that was in there historically and rebuilding reporting.  A lot of that, I believe, will be able to be fixed by AI. And it’s no longer for me just a belief. I know it’s real, because I’m seeing it happening in different companies I’m talking to or working with and it’s fun. And frankly, I’ll just give you guys a shout-out. You’re on your track with the products you guys develop. I’m seeing good things. It’s exciting to see what you’re building, and where this will lead to.

Sherry: Thank you so much, Jon, and from your experience in the finance industry, can you provide an example of how automation might improve GL coding practices in a specific industry?

Jon Naseath: Yeah. The manufacturing industry is complex a bit, because it’s not all just kind of in the cloud, SaaS, and I’ll say relatively easy. So there are so many different stages of raw materials, work in progress, finished goods, making sure you’re coding things all to the right place and then, making sure it’s current. I think that speed aspect is really important, because then, if you don’t get it right in time, you’re making accruals, and you have to fix them later. So I think that can reduce a lot of human error and complexities when things go away. And I think automation will fix a lot of that stuff.

Sherry: And what best practices would you recommend for companies, or for our viewers looking to implement or improve their GL coding system?

Jon Naseath: Sure. Don’t get overloaded is the way I like to describe it in your GL. Keep it relatively simple. Think about what is the core dimension of your GL, and then what the sub-dimensions, and sub-ledgers that tie into that. Make sure people have the training they need so that they’re not screwing your stuff up. I remember a friend of mine was in accounts payable, and he had a paper on his screen. He would just keep, and all he was doing was coding things to those key numbers, and that master table. When I come into a new company, I’ll, based on that, go around and ask the people in these types of roles: “Show me your kind of cheat sheet. What’s that master thing for mapping that you rely on?” And they all have them. They all pull out, “Well, this is what I look at, this is what I rely on.”I like to take those cheat sheets, standardize them into policy, and make them real. Use technology wherever possible. I do think AI is great, but I think that there’s lots and lots, you know, throughout my whole career there’s been automation of things. So there are lots of things that are proven as technology automation, use them. We don’t need to reinvent AI just to do something that’s already fully automated. And then use AI for stuff that couldn’t have been automated previously. That is now enabled. And the combination of those two things is where you get really powerful results and then just basic, I’ll call them controls. Reconciliations, making sure that things are coded correctly, doing budgeting, and making sure you’re doing those plans versus actuals. The best call out here is to partner with FP&A, finance, and accounting. Accounting wants to get their numbers right. They’re very proud of that. But then it’s FP&A that is creating the management reporting a lot of times and a lot of the forecasting. So if those numbers are off, work together to make sure they’re right before you go spread it all over the business and tell them that they’re idiots because they screwed up some number when it was an accounting-finance disconnect. That never happens, but just hypothetically.

Sherry: Thank you so much, Jon, for these valuable insights on GL coding practices, and how technology can play a crucial role in maintaining financial integrity.

Jon Naseath: My pleasure, always fun.

Chart of Accounts (COA) and GL coding for SAP

Find out interesting insights with John Silverstein, VP of FP&A, XR Extreme Reach

Moderated by Emily, Digital Transformation Consultant at Hyperbots

Don’t want to watch a video? Read the interview transcript below.

Emily: Hi, everyone. This is Emily, and I’m a digital transformation consultant at Hyperbots. I’m very pleased to have you on the call with me, who is the VP of FP&A and taxes at Extreme Reach. Thank you so much for joining us today, John. It’s great to have you.

John Silverstein: Thank you for having me.

Emily: So, John, we are here to discuss the best practices and common challenges related to GL coding and the chart of accounts in SAP, especially when dealing with multiple legal entities across different countries. So let’s just dive right in. Why is it important for an organization to have a well-structured GL coding scheme in SAP?

John Silverstein: Yeah, thank you. It’s really important to have structured GL coding and controls around it because it provides a standardized way, as you said, for multiple legal entities across the globe. If you have different structures, it’s going to be impossible for systems to know what’s in those different entities, and consolidations become very difficult. This structure enables clear financial reporting, reduces reliance on mapping tables, and ensures more consistency across the globe. You’ll also have accurate decision-making, as it helps avoid confusion between different types of accounts. Additionally, it ensures compliance with local and international accounting standards. A consistent coding scheme also allows for quicker consolidation of financial statements. Without it, taxes and audits can become quite complicated.

Emily: Got it, understood. Moving forward, what are some of the best practices you would recommend for designing a GL coding structure in SAP?

John Silverstein: The biggest thing is consistency. Ideally, you want one chart of accounts from a global standpoint, with rules and descriptions that everyone can use. This consistency should apply across the globe, not just within one legal entity. At the same time, you need granularity—maintaining an appropriate level of GL codes to categorize your assets, liabilities, and expenses properly. For example, using consistent standards like 1,100 for cash or 1,200 for accounts receivable. This helps roll up financials smoothly without overcomplicating the structure. You also need to align the structure with business needs, which can be challenging. Don’t use GL accounts for everything. Sometimes, companies confuse GL accounts with cost centers or product codes, making things unnecessarily complex. For instance, if you’re a retail company with multiple sales channels, separate revenue accounts for each channel, like online sales versus in-store sales, help track profitability more accurately. It’s also crucial to regularly review and update the coding structure to meet business requirements, especially as new lines of business or clients emerge. I’m currently working on a project to clean up our chart of accounts to ensure it’s updated and reflects our business structure properly. Automation and validation within SAP can further reduce errors, especially through the automatic allocation of expenses to the correct cost centers.

Emily: Thank you so much for that answer. It adds a lot of value. What are some of the common errors or mistakes companies make when managing their GL coding structure?

John Silverstein: A common mistake is using different coding or number schemas across entities. Sometimes, even within one entity, you see inconsistent number schemas. For example, marketing expenses might be coded differently across departments, which can create confusion during consolidation. Another mistake is overcomplicating the GL structure, such as creating a GL account for every vendor or customer to track profitability. This is not scalable, especially as the business grows. Using dimensions like cost centers or product codes to map out profitability is much more effective. Improper account mapping is also common. Travel expenses, for instance, may be scattered across different categories like car rentals, creating unnecessary confusion. Duplicate accounts are another issue; it’s common to see multiple office expense accounts or consulting fees that should be consolidated. Neglecting legal requirements, such as VAT accounts in European countries, can also lead to non-compliance.

Emily: Got it. How do you handle multiple legal entities of the same company in different countries from a GL coding perspective?

John Silverstein: You need to assign unique company codes for each legal entity in SAP, which allows for separate ledgers and easier consolidation. For example, you might use US01 for the US entity and UK01 for the UK entity. Ensuring that the codes are consistent is critical for proper roll-up and reporting. Multiple charts of accounts are necessary for local statutory compliance, but there should be a group chart of accounts for consolidation. For instance, cash might be represented as 1,000 across all entities, but VAT receivables might be specific to the UK, and sales tax receivables might apply to the US. Intercompany transactions also need to be managed carefully with distinct GL codes for intercompany payables and receivables. Automation through SAP’s intercompany reconciliation tools helps minimize errors.

Emily: Got it. Can you also provide an example of how a company can ensure compliance and accuracy when dealing with multiple currencies across different entities?

John Silverstein: Sure. Let’s say a US-based company has subsidiaries in the UK and Japan. SAP can handle transactions in local currencies, such as GBP and JPY, and simultaneously record them in group currency (USD) and possibly a global currency like EUR. This allows for consistent financial reporting at a consolidated level while ensuring local compliance. 

SAP’s foreign currency valuation tools help adjust GL balances according to current exchange rates. For instance, if the Japanese subsidiary records a sale in JPY, SAP can convert that into USD for group reporting and automatically adjust balances for exchange rate fluctuations.

Emily: That makes sense. So, how can AI help prevent common mistakes in GL coding for SAP?

John Silverstein: AI can help in several ways. It can automate data entry, ensuring consistency and accuracy while reducing human errors. AI can learn from past transactions and suggest GL codes for new ones, improving over time with continuous learning. Anomaly detection is another big area—AI can flag transactions that don’t align with established patterns or rules. For example, if a travel expense is coded to an unusual account, AI can alert the user immediately. Natural Language Processing (NLP) tools also help categorize documents like invoices and receipts, automatically assigning them to the correct GL accounts. This is particularly helpful when dealing with diverse formats and languages. Predictive analytics can help forecast potential errors based on historical data, and continuous learning means that AI will get better at detecting and correcting errors over time.

Emily: Got it. What strategies would you suggest for aligning GL coding practices across multiple countries while ensuring compliance with local regulations?

John Silverstein: Centralize the group chart of accounts, but allow for local flexibility to meet statutory requirements. This means having a global chart of accounts for consolidation while still letting local entities maintain country-specific charts for regulatory compliance. SAP’s localization features, like country-specific tax codes, can help meet regulatory requirements. Standardizing processes across the organization, such as using consistent templates for financial reporting, is also essential. Regular training and reviews are crucial to keep up with changes in business needs, regulations, and technology. Maintaining clear communication between global and local finance teams ensures alignment across the board. At some scale. So you need to make sure that the technology changes. So you need to ensure that people know what they’re using. They’re not using the old versions of all your software and technology that you have out there.

Emily: Got it. And just to wind things up. One last question, John. So how does a well-structured GL coding scheme contribute to faster financial reporting and better decision-making overall?

John Silverstein: Yeah. So this is you. If you screw up the GL coding, you sometimes can’t report on things until you’re done with consolidations and going through mapping tools and all this other stuff, it gets very complex. And you end up catching errors during the close process, or too late in the process that you can’t, that you end up going back and forth. It adds days and unnecessary work. During your close process, your data will be inconsistent. You’re gonna make mistakes, and you’re gonna catch these too late. Is a big part of it. So, one of the most critical things you can do is to make sure that you are consistent and the automated reporting, if it’s manual reporting today and there are inconsistencies all the time, you end up doing corrections all the time, and then your accounting is not correct. So if you don’t do this right, you’re gonna make mistakes, and it can cause restatements, even in tax restatements and all that stuff as well. So very critical.

Emily: Got it. Got it. Thank you so much, John, for joining us today again. It was an insightful discussion, you know, talking to you about the chart of accounts and the GL coding for SAP in particular. So thank you so much for joining us.

John Silverstein: Yeah, no problem.