Dynamics 365 General Ledger - Simply Explained

Welcome to another episode of Microsoft Knowledge Nuggets here on M365. FM, I'm your host, Mirko Peters. Today's topic is one that almost everyone has heard of, but few can explain in plain English. The General Ledger. Money moves through a company all day as customers pay invoices, someone approves, suppliers bills, payroll runs, stock arrives and money enters or leaves a bank account, and each of those events changes the company's financial picture. So what exactly is the General Ledger? Is it just another screen inside Dynamics 365 finance, full of accounting words that only finance people understand? It isn't. Think of it like the Master Ledger book in an office building. Every money event needs a place in that book, under the right heading, so the company can later see where its money came from, where it went and what remains. By the end of this episode, you'll understand what this actually is and how the pieces fit together. We'll start with the problem the General Ledger solves. The General Ledger. The company's Master Money Record 560 words. Imagine running a company with a spreadsheet for sales, another for supplier bills, a separate tool for payroll, and somebody's private file for bank payments, and that can work for a while. But soon, finance asks a simple question. How much cash do we have right now? One spreadsheet shows one number, the bank file shows another, and the sales team has a third number because the payment hasn't been copied across yet, so nobody knows which number belongs in the report. Here's the thing, that's the problem the General Ledger solves. It gives the company one financial record where all the accounting entries come together in a consistent way, instead of leaving finance to piece together numbers from disconnected files. In plain English, the General Ledger is a register of the company's debit and credit entries. Those entries sit under accounts like cash, sales revenue, rent expense, inventory, or accounts payable. You don't need to panic over debit and credit yet. Instead, think of them as the two sides of every financial event. When value enters one place, the system records where that value came from, or what the company now owes, and the two sides always match. That matching rule keeps the books balanced. Now let's talk about how Dynamics 365 Finance organizes this. It keeps the Ledger for each legal entity, which is the company that keeps its own financial records, submits its own reports, and may have its own tax and banking responsibilities. For example, a group might include a company in the United Kingdom and another in Germany, and while they can work together, each company needs its own financial record because each one has its own money, obligations, and reporting needs. So each legal entity gets one Ledger, the Ledger needs a few building blocks before people can post financial entries. The first building block is a chart of accounts, the list of account names and numbers that organize the company's money. It also needs a fiscal calendar that tells Dynamics 365 Finance how the financial year breaks into periods like months. And without it, the system can't place a transaction in the right accounting period, or help finance prepare a month and report. Then there's the accounting currency, sometimes called the home currency, which gives the Ledger a common money language for its financial records, even when the company buys or sells in other currencies. It's a company that buys stock in euros but prepares its accounts in British pounds. The purchase still needs to land in one central financial record using the company's accounting currency for its own reports. Those settings may sound like setup details, but they shape every posting that follows. So why does finance care so much about one shared record? Because reports need a number people can trust. And when a manager opens a balance report, they need to know it comes from the same financial record that supports the company's income statement and balance sheet, without having to ask whether someone forgot to update a spreadsheet after entering an invoice. The general ledger gives finance that common source. It doesn't replace the work happening across the company. People still buy products, send invoices, pay vendors, receive stock and run payroll, but the financial impact of those events reaches the ledger in a controlled form. That gives finance a clear answer when someone asks, why is this balance here? Double entry bookkeeping keeps that answer honest because every posted amount has an equal entry on the other side. So if the company records a debit of 100, it also records a credit of 100. No mystery math. The accounts change depending on what happened, but the total debit and total credit must balance and Dynamics 365 finance follows that rule when entries reach the ledger, helping stop a one-sided financial record from slipping into the books. So the general ledger is not a place where numbers go to disappear. It's the company's master money record built on shared rules and balanced entries, but a record this large needs a clear filing system and that starts with the chart of accounts. Chart of accounts and financial dimensions. The filing cabinet. Welcome back to Knowledge Nuggets. I'm Mirko Peters and today we're opening the financial filing cabinet out the chart of accounts and financial dimensions. So where does a transaction go once it lands in the ledger? It lands in an account. The chart of accounts is the structured list, a legal entity uses to sort its finances, picture it like a filing cabinet with label drawers. Each drawer has a purpose and every transaction needs to find its home. Just those labels, a company might know money moved, but it couldn't explain what that money meant. The chart of accounts holds the main accounts or the broad financial labels for transactions. Cash is a main account and so are sales revenue, rent expense, accounts payable and inventory. When a company pays office rent, money leaves cash and the cost goes into rent expense. Buying products for later sale puts value into inventory, receiving an unpaid supplier bill places the obligation in accounts payable. Each main account gives every entry a clear home. It's a simple idea but it shapes every finance report. Accounts fall into larger groups that finance users to prepare the balance sheet and income statement. Assets, liabilities and equity belong on the balance sheet, describing what the company owns, owes and the remaining ownership. Revenue and expenses go on the income statement, which answers a different question. Did the company earn more than it spent this period? Cash and inventory are assets. Accounts payable is a liability our money owed to suppliers. Sales revenue records income from goods or services, rent expense records operating costs. When accounts have the right categories, dynamics 365 finance can place amounts in the correct part of a financial report. But an account name alone often doesn't tell you enough, say you have one account called travel expense. It tells you money was spent on travel but it doesn't say who spent it or which part of the business paid. That's where financial dimensions come in. These are extra labels attached to every entry of things like department, cost center, business unit or location. Think of the main account as the subject line on a form. Dimensions fill in the details beneath. Local expense tells you the, what department might tell you it belongs to sales. Cost center could identify the team budget. Business unit separates company sections. Location shows whether the cost belonged to London, Berlin or another office. Now picture three employees booking flights for customer meetings. All three costs post to the same travel expense main account. But one entry carries sales as its department, another carry support and another carry finance. Finance can then look at total company travel spending. You can ask a sharper question, how much did sales spend on travel this month? How much did support spend? Did finance stay within its budget? The spending didn't need separate main accounts for each team. Awe, the dimensions provide those separate views. A company doesn't want people picking random labels and creating messy records. A travel cost might need a department and cost center, while a bank entry needs fewer details. Dynamics 365 finance controls this through account structures and rules. An account structure sets the allowed combination of main account and dimensions. In plain English it tells the system which labels go with which account and which values people can choose. For example, a travel expense entry might require a department and cost center. A cash entry might only allow a business unit. If someone tries to post a rent expense with a location that doesn't belong or leaves out a required department, the system stops the entry before it reaches the records. That keeps reports clean because the rules guide people right at the moment they enter the transaction. Larger organizations can also share one chart of accounts across several legal entities. They all use the same account list or cash sales revenue inventory or making group reporting easier to compare. But shared account names don't merge the companies into one record. Each legal entity keeps its own ledger. Imagine two companies using the same filing cabinet design in separate offices. The drawer labels match, but the papers inside belong to different companies. One company's cash balance doesn't mix with the others. So the chart of accounts tells you what each entry means. Financial dimensions add business detail. Account structures ensure the right combinations. But these labels only explain where an entry belongs. The next question is where that entry started and that takes us to sublegges. Ledger and sublegges, where transactions begin. Now let's talk about where all those transactions actually start. The general ledger holds the financial record for the whole legal entity, but it doesn't carry every day to day detail. That distinction saves a lot of confusion. When a buyer receives a vendor invoice, the business needs to know the vendor name, invoice number, due date, purchase order, payment status, tax details, and sometimes the line items. Finance needs the accounting result, but a financial report doesn't need to show every line from every supplier document. That detailed work lives in sublegges. A sublegger is the part of Dynamics 365 Finance that tracks detail for a specific kind of activity. Accounts payable tracks vendor invoices amounts owed and payments. Accounts, receivable tracks customer invoices, incoming payments, and what customers still owe. Factory tracks stock movements and value, fixed assets, tracks equipment, vehicles, or buildings the company owns long term. The tax module tracks tax codes and amounts. Production tracks the financial side of manufacturing, our materials, labor, and other costs that affect the final item cost. Each module keeps the detail its users need, but that doesn't mean these modules work in isolation. They feed accounting entries into the general ledger, keeping operational activity and financial records connected. Take a vendor invoice. Someone in accounts payable enters an invoice from a supplier. They see who sent it, what it covers, when payment is due, and whether it matches the purchase info. That's the document level view. Behind that invoice Dynamics 365 Finance creates the accounting effect, maybe the supplier charged for office rent. The system records the expense in the right account, and records the amount owed in accounts payable. The invoice stays visible in accounts payable, while it's debit and credit entries pass into the general ledger. One business event creates two useful views. The operational view asks, which supplier do we need to pay and when? The accounting view asks, which accounts changed because of this invoice? You might wonder how the system knows which accounts to use. Nobody wants staff guessing every debit and credit account while entering a normal invoice. Dynamics 365 Finance uses posting profiles for that. A posting profile contains rules behind the scenes that point the system to the correct main accounts for a transaction type. In accounts payable, a vendor posting profile can direct the owed amount to the accounts payable account. Other rules based on the invoice details direct the other side of the entry. Think of posting profiles as accounting instructions built into the process. People still enter the real business document. The system applies the company's financial rules using the accounts and dimensions allowed for that activity. That creates a more consistent result than asking every user to decide the accounting from scratch. There's also a shared reference that helps follow the trail, it's called a voucher. A voucher links the source document, the sub ledger accounting entries, and the entries that reach the general ledger. If a finance user sees an amount in the ledger and needs to know where it came from, the voucher helps trace it back to the source. That matters when someone asks a very normal question. What is this amount? Instead of searching across reports, emails, and folders, the team can follow the voucher from a ledger entry to the vendor invoice, product receipt, customer invoice, or other source document. The voucher doesn't replace the original document, it connects the financial record to that document. So when you open a vendor invoice in accounts payable, you're looking at the business document and payment details. When you open the voucher or ledger transactions, you're looking at the financial posting behind that document. Same event, different purpose. This split lets operational teams work with the detail they need, while finance can review organized account balances and prepare reports without turning every report into a long list of invoice lines. The general ledger stays focused on the accounting record. Sub ledgers keep business detail close to the people who need it. Vouchers and posting profiles connect both sides, so a number on a report can still lead back to the event that created it. Now let's follow a simple purchase from ordering goods through to the accounting entries it creates. A purchase example. How money moves through dynamics. 365. So your company orders 100 office chairs from a supplier. The process starts with a purchase order. That document outlines what the company plans to buy, from whom, at what price, and how many chairs. At this point it's just a commitment, oh, a plan, not a transaction. The chairs haven't arrived yet, and no invoice has been sent. When the delivery shows up, someone records a product receipt inside dynamics 365. This step confirms the company actually received the chairs. Inventory goes up because you now physically control 100 more chairs. And right at that moment, dynamics 365 can create an accounting entry for the receipt. Let's simplify that. Say the chairs cost $10,000 in the company's accounting currency. Inventory gets a debit of $10,000, purchase a cruel gets a credit of $10,000. Don't let those terms confuse you. A debit simply records that value entered inventory, oh, the company now owns items worth $10,000. The credit records the other side, the amount tied to goods received, but not yet billed. Besides equal $10,000, so the company has the chairs, but no invoice yet. Purchase a cruel acts as a temporary holding spot, a yo, a placeholder between receiving the goods and getting the bill. It says, we received value and we expect a vendor charge to match it. Both sides are equal, which is exactly what the system needs. That balance matters because dynamics 365 checks that total debits and total credit match when it creates the accounting entry. If only the inventory side existed, the records would show extra value without showing where it came from. Accounting doesn't work that way. The amount needs two sides, our source and a destination. A few days later, the invoice arrives, the accounts payable team enters and posts it. The system can match the invoice to the purchase order and the product receipt so the company can compare, what it ordered, what it received and what the vendor charged. When the invoice posts, the temporary purchase a cruel amount clears. The system debits, purchase a cruel for $10,000, a yo, reducing the amount held there, oh, and credits accounts payable for $10,000. That's the thing what the company now owes the vendor. Notice what changed here. The inventory posting already recorded that the chairs arrived. The vendor invoice doesn't add the chairs a second time. It just changes the company's obligation from a temporary placeholder to a specific amount owed to a specific vendor. That gives different teams exactly the information they need. The warehouse team confirms the chairs arrived. The buyer checks the purchase order. Accounts payable sees the invoice and payment due date and finance sees the accounting entries that moved through inventory purchase a cruel and accounts payable. There's one purchase, but each part of Dynamics 365 records only the piece that belongs to it. Every posting also gets a voucher reference. Say a finance manager sees a $10,000 movement in the inventory account on a report and wants to know why. They can use the voucher to trace that amount back through the product receipt, the purchase order, and eventually the vendor invoice. That turns, where did this number come from? Into a traceable question. The trail goes both directions. Someone reviewing the invoice can open the related financial posting. Someone reviewing the ledger can trace back to the document that started the entry. Those spreadsheets often break this link, one person updates an inventory file. Someone else enters a vendor bill into an accounts file, finance copies totals into another workbook at month end. A missing row, a changed amount, or a late update leaves the records out of step. Dynamics 365 keeps the purchase activity and accounting entries connected as the work happens. People still need to enter accurate information and follow the company's approval process or the system won't turn a bad invoice into a good one. But it reduces repeated entry and keeps the original documents close to the financial postings they create. That single purchase creates only a few entries. Across a normal day, a company posts many more. Those postings build the financial record and finance uses them for recurring work throughout the accounting period. What finance does with the ledger? Daily work, period close, and tax. Not every accounting event starts with a purchase order, invoice, or stock movement. Sometimes finance needs to post a journal entry directly. A journal entry records an adjustment or a financial event that comes straight from the finance team are you like correcting a posting, recording in a cruel, or moving an amount between accounts at period end. It gives finance a controlled way to record work that doesn't start in another part of Dynamics 365. Imagine an electricity bill covers the last few days of March, but the invoice won't arrive until April. Finance can post in a cruel in March, so the March accounts include the costs that belongs there. When the invoice arrives later, the team handles the actual document that keeps the financial period focused on what happened during that period, not just on when paperwork came in. It also uses allocations. An allocation distributes an amount across other accounts, departments, or cost centers using rules the company defines. A fixed allocation follows set percentages. If head office rent should split 50% to sales, 30% to support, and 20% to finance, the system applies those percentages. A variable allocation changes based on a measure. For example, shared warehouse costs might spread across business units based on how many items each unit handled. One team uses more of the warehouse so it receives more of the cost. The original cost remains traceable, while reports show where the business chose to carry that cost. Tax needs the same kind of control. Dynamics 365. Finance uses sales tax codes to store the information needed for tax posting. A tax code can define the rate or amount to collect or pay, along with the method used to apply it to a transaction. Tax requirements differ by country, region, state, county, and city. So the code gives the system rules for the tax part of a sale or purchase, rather than leaving users to type a different calculation each time. When rules change, the company updates the tax setup, no need for handwritten notes or remembering exceptions. Then comes the rhythm of the financial year. A fiscal calendar splits the year into periods, often months. As each period ends, finance reviews the entries, posts needed adjustments, and prepares reports for that slice of time. At year end, closing transactions prepare the income statement accounts for the next fiscal year, revenue and expense accounts track activity during one year. After the year closes, those accounts start the new year ready to record new income and new costs. Their completed result moves into the company's equity through the closing process. Balance sheet accounts work differently. Cash, inventory, accounts payable, and other balance sheet accounts carry their balances forward because the company still owns the cash or stock, and still owes any unpaid bills when the new year begins. Large groups face one more task. A parent organization may need one view of results from several subsidiary legal entities. Consolidation combines financial results from those companies into a single organization view I/O, even when the subsidiaries sit in the same database or separate databases. The individual company still keeps their own records. Consolidation gives the group a combined financial picture, so daily journals, allocations, tax postings, period work, year end closing, and consolidation all use the same financial foundation. Next, let's put those building blocks together without turning period close into an admin lesson. Putting the picture together. Think of the general ledger as your company's main financial filing cabinet. The chart of accounts names each drawer, dimensions add labels, and the calendar and currency set the rules for every entry. Subledgers send their detailed activity through balance postings, and vouchers keep a trail back to the original source document. That chair purchase? It moves from a daily transaction all the way into the financial statements, with a record someone can trace later. The general ledger isn't just data entry, it's how finance explains the company's financial position. Conclusion All the money. Follow a Dynamics 365 Finance Transaction through its account, dimension, source document, and voucher. Everything becomes much clearer. Subscribe on your favorite podcast platform and share this knowledge nugget with someone learning Dynamics 365 Finance.