In every organization, all kinds of expenses and revenues are tracked under dimensions like cost centers, departments, employees, etc. It is often a business requirement to split expenses or incomes in fixed proportions between two or more dimensions for accurate reporting.  On the other hand, it may be required to assign a dimension only on one GL account, restricting it from others. D365 Finance offers a smooth, flexible and a very easy process to fulfill both kinds of requirements to achieve accurate reporting of the organization’s P&L from a dimension standpoint. The blog assumes the reader is already aware about setting up financial dimensions and using them for regular transactions so the point of focus will be on the advanced features only. The procedures for both requirements are as follows: – Let’s assume that an organization tracks all kinds of office expenses in two dimensions – department and cost center. The organization wants to split the cost in a 70:30 proportion between both. In order to do that, we will use Ledger Allocation Journals. Path – General Ledger -> Allocations -> Ledger Allocation Rules The source defines the main account that will be used to split the amount. The Destination defines the dimensions and the proportion in which the amount will be split between them. In the General tab, we define the validity date for which the rule will be active. The allocation method defines the various methods in which the GL amount can be distributed. Most often, the splitting is in fixed percentages. Turn the Active checkbox to activate the rule. In the source, define the main account. In Destination, define the percentages of distribution. From the above image, we are using a 70:30 distribution ratio between Cost Center and Department.  Here, we have defined a default dimension so that the system will know how to distribute the amount between the cost center and the department only. It will ignore any other dimension. If the default field is left blank, then the user will have to manually select the dimensions at the time of the transaction. In the first distribution, a fixed percentage of 30% is applied to the Cost Center. Create a new distribution again and allocate the remaining 70% to a department dimension. In this example, we are using only 2 dimensions, but the user may define as many distributions between multiple dimensions as required as long as the percentages add up to 100%. Save the rule and close it. Now, create any regular transaction with the GL account, like a general journal. Select the dimensions for the cost center and the department as shown above and post the document. Once posted, go to General ledger -> Ledger Allocations -> Process Allocation Request. Select the allocation rule. In the field Proposal Options, there are two options: – The first option will directly post the entry and allocate it to the dimensions. The second option will keep the entry unposted so that the user may verify the dimensions or make changes to them manually if required. It is always preferable to select the second option. Upon clicking Okay, the system will create an allocation journal as shown below: – Upon clicking open the allocation journal, the accounting impact is shown as below: – The accounting impact can be summarized below as follows: – GL Account/Dimension Description Dr Cr 5103-007 Office Expense – Cost Center 700   5103-257 Office Expense – Department 300   5103 Office Expenses   1000 From the above ledger impact, the GL balance stays the same, but the amount gets distributed between the 2 dimensions in the exact proportion. II. Using advanced rules to assign an additional dimension to a particular GL account only. To understand this requirement, let’s take the example of an organization that has a mandatory Department dimension assigned on all expense accounts. But there may be an exceptional case where one expense GL account requires one more dimension apart from Department.   In this case, if we add a dimension in the account structure, then that dimension will be needlessly assigned to all GL accounts. We must ensure that it should be applicable to the one account only. For this, we use the concept of Advanced Rules. With the help of Advanced Rules, we can configure the Account Structures to accommodate any additional dimension for one particular GL account only. The steps to configure it are as follows: – Go to: General ledger -> Chart of Accounts -> Structures -> Advanced Rule Structures The screen displays all the Advanced Rule Structures present. Create a new one. Select the dimension that is required. In this example, we have selected the dimension of ‘Worker’ and kept it as mandatory. Activate the Advanced Rule Structure and close it. Open Account Structures. From the above image, all the GL accounts here will have a mandatory Department dimension. But let’s assume that one GL account – 4101 will require the dimension for Worker along with Department. For that, open Advanced Rules on top. Create a new rule. Select the Main Account where you want to apply the dimension as shown above. Then in the below section, add the Advanced Rule Structure that was created earlier. The rule works like this: – If Main Account = 4101, then apply Advanced Rule Structure where dimension = Employee. Therefore, in any transaction with the account 4101, it will assign the Worker dimension on it. Let’s take an example where a GL account other than 4101 is used here. In this transaction, for the account 4102, the system is prompting us to select the Department dimension only, as required. Now let’s select the account 4101. As observed from the above image, the system is now prompting us to select the Worker dimension also. Thus, this ensures that only some GL accounts may be configured to enter an additional dimension. We can also configure the rules such that there are combinations of Main Accounts and Dimensions to add any additional dimension. … Continue reading Distributing GL amounts between financial dimensions and using advanced rules to link a dimension to only one particular account →

While electronic methods of payment are becoming increasingly popular everywhere for quick payments, check payments are still popular across the world, especially post dated checks, which can be cashed out only after a specified date, giving them an edge over electronic payment methods. D365 Finance has a very simple process to create post dated checks and account their entries.  Since post dated checks are cleared after a certain date, known as the maturity date, the amount is not directly accounted in the bank account, but to a bridging account instead. A bridging account serves as a ‘bridge’, for the transaction amount between the bank account and the vendor/customer account till the maturity date of the PDC. When a payment entry with a PDC is made, the system will store the amount temporarily in the bridging account till the maturity date. On the maturity date, the system will transfer the amount from the bridging account in the bank account. The accounting process of the PDC is summarized below: – For Vendor:- PDC (Before Maturity) Dr Cr Vendor XX   Bridging Account   XX PDC (After maturity) Dr Cr Bridging Account XX   Bank   XX For Customer: PDC (Before Maturity) Dr Cr Customer   XX Bridging Account XX   PDC (After maturity) Dr Cr Bridging Account   XX Bank XX   The steps to set up and use PDC are as follows: – 7. Select the Account type as Bank. 8. Enable the parameters for Bridging posting and Post Dated check clearing posting. 9. The bridge account gets selected automatically by default based on the one defined in the Cash & Bank management parameters defined earlier. 10. Do the exactly same setup in AR module -> Methods of payment as well. This concludes the setup part. Now we can proceed with the transactions. Process: – Go to Postdated Checks tab and enter the maturity date for the PDC. Until the maturity date is reached, we cannot settle the PDC. So either we can wait till that date or for the sake of testing purposes, we can set the system clock to a future date. This concludes the configuration and process for PDC in D365 Finance.

In any ERP, any accounting user might want to set up periodic journals on a monthly/quarterly/year basis for recording the costs of any services, like AMC charges, rents, subscription fees, etc. It can get tedious to manually create such entries every single time indefinitely. This can lead to errors and unnecessary time consumption if the entries are very long and made to multiple business partners. Dynamic 365 Finance offers an easy way out through the use of periodic journals. Periodic journals help the user create entries periodically in the system. With periodic journals, users can: The process of configuring and using periodic entries is very simple. Setup 1. First, configure a journal name with the Journal type as ‘Periodic’ as shown below: 2. Then go to General Journal -> Journal Entries -> Periodic Journals Here, we define the template for the periodic journal entry to be created in future. Create a new entry. 3. Select the date on which you want the periodic journal entry to be created. 4. Select the GL accounts and their amounts. You can create a single line journal entry with an offset account or you can create a multi-line entry with as many GL accounts as required. 5. Select the Unit. Unit stands for the period of the journal entry – days, months or years. 6. Enter the number of units. This is the frequency of recurrence of the journal entry. For e.g., if you select Unit as months and enter the number of units as 3, then the periodic journal entry will be set to repeat every 3 months from the beginning date. Working 1. Open a General Journal entry. 2. Create a new entry. 3. On the top, click on Period Journal. 4. There are 2 options – Retrieve Journal and Save Journal. Retrieve journal is used for retrieving a periodic journal that we have just setup. Save journal is used if you want to save any existing journal entry as a template for a future periodic journal entry. 5. We use Retrieve Journal to retrieve the template we have created above. 6. In the ‘To Date’, enter the date of recurrence, i.e., the date for which the entry repeats for the period. In the Periodic Journal number, select the Periodic Journal which was created earlier. In the last field, there are 2 options – Copy or Move. Copy will fetch the periodic journal data into the journal entry and update it for use in the next period. Move will also fetch the journal data but will block the periodic journal from being used in future. Use the move option if you know that the periodic journal is not going to be used anymore. 7. The system will load the data as shown below:- 8. As you may notice, the date field is as per the date selected in the Retrieve Periodic Journal, while all the other details like the GL account and amounts are fetched exactly as per the template. 9. Once you post this journal entry, the journal date in the periodic journal template will be updated to the next period, in this case, to 1st of December. 10. In order to check if the date has been updated or not, simply go to the Periodic Journal once more and check the date. As you may have noticed, the date got updated to the next period of recurrence. So when you retrieve this journal for the next time, it will fetch the journal based on this date. This can go on as many times until you select the option to Move instead of Copy. After that, the periodic journal will stop updating and won’t be able to be used again. Through this process, the user can fetch the journal entries periodically instead of creating them manually every time. While the fetching of the data is automatic, the user will have to make sure to run the periodic journals as per their dates. There is an option to automatically generate the entries in the system through Power Automate but that is a separate Add-on to be setup and configured. The standard process is just as good enough to reduce the hassle for making entries manually every period.

Introduction In any accounting software, it is always important to keep track of all real-time bank transactions and record them in the ERP. Since bank transactions are booked manually in the ERP, it is necessary to ensure that the bank statements and ERP records are matched on any given date. This is where bank reconciliation comes into play. Bank Reconciliation Bank reconciliation is an activity done by any finance user for the purpose of reconciling book transactions w.r.t bank statements and ensuring that both are as closely matched as possible. D365 Finance offers two ways of performing bank reconciliations. One is by entering the bank statement amount manually and reconciling the ERP statements for each record against the amount. The other is by importing the bank statement into the system and letting the system match the records of the statement against the ERP based on a certain criteria. The blog is made with the assumption that the reader is already aware of the manual bank reconciliation process in D365 Finance. The second method is undoubtedly easier, flexible, and time-saving for any user. While there are several widely used bank statement format types which can be processed in D365 Finance like MT490, CAMT.054, BAI2 and others, this blog post will be focused on the MT490 format only. Moreover, D365 Finance also enables the user to reconcile not only payments/receipts, but also transactions from the bank’s side, like bank charges, interest fees or reversals and post those entries into the ledger automatically. There is also a flexibility to create a set of rules that can allow for minor amount/date variations of the system w.r.t the bank statement. Steps to perform the bank reconciliation in an automated manner Setup We have to enable the system to accept bank statements in MT940 statement first. In order to do that, navigate to, Organization Administration > Workspaces > Electronic Reporting Click on Repositories. Select Global and click Open on top. Filter the Configuration name by searching for ‘MT940’. The above list of formats will be displayed. Select them all and click on Import. The system will import the bank formats in D365 Finance. Next, we have to map the format in a setup. Go to Cash & Bank Management > Advanced Bank Reconciliation Setup > Bank Statement Format Create a new record and specify the Statement Code, Name and map the Import format which was imported in the previous step. Now this is done, the only part left is to configure the Bank master to enable advanced bank reconciliations for any transactions. Open the Bank Account Master. Turn on ‘Advanced Bank Reconciliation’ and select MT940 in the field Statement format. Once this is done, we are ready to use Advanced Bank Reconciliation. Working To start with advanced reconciliation, we will take a scenario of a bank where the following transactions have occurred: The above 3 transactions are created in the system and will be reconciled with the use of a bank statement. The bank statement will be a notepad file that will be imported in the system. While the bank statement is always provided by the bank, it is important to know the bank statement format so we can setup and test any scenario with dummy records. The above screenshot specifies the structure in which the bank statement is accepted by the system. We will be using this format to import bank records and reconcile them with the system records. From the above image, 3 types of bank transactions have been made in the system with the respective amounts and dates. Now the bank statement file for the above transactions is as follows: As you may observe, all three transactions are recorded one below the other, and the opening and closing figures are manually entered here. In real-time scenarios, this is provided by the bank and the user does not open or make any changes to the file. In order to import the file, go to Bank Account > Bank Statements > Import Statement In the parameters, select the bank account, browse the text file from your PC and click on upload, then click on OK. The bank statement is imported with the above transactions. Select the transactions and click on Validate on top. Now we proceed with the reconciliation. Go back and click on Bank Reconciliation in the Bank Account screen. Create a new reconciliation. Then click on Worksheet at the top. The reconciliation screen is opened. Here, the user is presented with the option to manually match any record to reconcile or let the system match the records based on a certain matching rule. While any variation of rules can be defined, the most commonly used rules are: Based on the above, we will define a matching rule based on date and amount difference and re-import the statement. To define a matching rule, navigate to Cash & Bank Management > Advanced Bank Reconciliation Setup > Reconciliation Matching Rules Based on the above image, the criteria for the match amount and match date is defined where a variation of 2 INR and 3 days will be allowed in reconciliation. Once it is saved, click on Activate. Next, navigate to Cash & Bank Management > Advanced Bank Reconciliation Setup > Reconciliation Matching Rule Sets Create a new rule set and link the matching rule that was created earlier. As you may observe, we can link multiple rules here. This is useful when it is necessary to reconcile statements with a variety of rules instead of a single rule. Next, go to Bank Account > Scroll down to Reconcilation section and link the matching rule set in the Default Matching Rule Set Now we are ready to run the reconciliation once more with some variations of amounts and days in the bank statement. Import the statement once more and validate it. The bank statement is imported as follows: Now create a reconciliation worksheet. On the top, select the option ‘Run Matching Rules’. Once the matching rules … Continue reading Advanced & Auto Bank Reconciliation in Dynamics 365 Finance →

In any organization with business spanning across multiple countries, multi-currency transactions play a vital role in day-to-day business. Any accounting software should be able to facilitate currency conversions not only at the time of booking the transaction but also calculating the forex gain/loss incurred during the end of any period or after settlements are made against open transactions. Dynamics 365 Finance & Operations offers an effectively simple functionality to facilitate such important transactions. Called as Foreign Currency Revaluation, it provides the following features: 1. Calculate the unrealized foreign currency gain/loss against all open transactions for any vendor/customer. 2. Account the unrealized gain/loss into the respective GL accounts. 3. Knocking off the unrealized gain/loss accounts by transferring the balance to the realized gain/loss accounts at the time of settlements. This functionality is beneficial to any accounting manager who wishes to know any gain/loss that might incur before making actual payments and make important business decisions accordingly. Dynamics 365 Finance not only has a very short and simple setup to set up Foreign Currency Revaluations, but also a very easy way to run the process. Setup Starting with the setup, the below settings need to be configured first: 1. Setup currency exchange rates Path: General Ledger -> Currencies -> Currency Exchange Rates As per the above screenshot, the user can have multiple currency conversion rates setup for any date range. 2. Configure main accounts for Unrealized Gain/Loss and Realized Gain/Loss As per different business requirements, the foreign exchange gain/losses can be accounted in a single GL account or multiple GL accounts. Based on that, the necessary accounts should be configured. They can come under Expenses or Revenue. 3. Link the main accounts to the Ledger For the system to account the gain/loss amount into the respective GL accounts, it is necessary to link them in the Ledger first. Path: General Ledger -> Ledger Setup -> Ledger 4. Enable multi-currency option in bank master Path – Cash & Bank management -> Bank account -> Enable the option “Allow transactions in additional currencies” This will enable the bank settlements to be done in any currency. 5. Lastly, Foreign Currency revaluation exists for each module (AP, AR, GL) and it is accessed directly without any setup. The setup is complete with the above steps. Now comes the process flow. As an example, the transactions will be run for the months of June and July where each month has a currency rate of 1 USD = 70 INR and 1 USD = 75 INR respectively. Based on these currency rates, the system will calculate a profit for customer payments and a loss for vendor payments respectively. Let’s start with the profit scenario first 1. Create a back dated FTI journal in the month of June. Select the amount as 1000 dollars. The accounting impact for the journal in USD and INR will be as below: FTI (USD) Dr Cr Customer 1000   Revenue   1000 FTI (INR) Dr Cr Customer 70,000   Revenue   70,000 2. Navigate to Accounts receivable -> Periodic Tasks -> Foreign Currency Revaluation Click on Foreign Currency Revaluation at the top. Clicking that will open the parameters window. Here, user can run the FCR for a specific vendor/customer. The considered date and Date of rate should be selected as the date when the new currency rate will take effect. In this case, it will be 1st of July, where the currency rate will become 1 USD = 75 INR. Click on OK. Once it is run, it will create an entry in the same screen as shown below: By default, the latest entries are at the bottom. Select the entry and click on voucher to see the effect. The voucher effect is as shown below: As per the above accounting impact, the system calculated that from 1st July, there will be a net gain for any customer payments against invoices made in June. Hence, the system will select the Unrealized Gain account and post the currency difference amount in it as an income. The customer’s outstanding balance also increases by the same amount. The simplified accounting effect is as below: FCR (INR) Dr Cr Unrealized Gain   5000 Customer 5000   Now if a payment is created in the month of July against the invoice booked in June, the system will post the payment journal as per the current exchange rate (i.e., 75 INR) and transfer the Unrealized amount to the Realized amount. This effect is as shown below: The simplified impact is as shown below: Payment (INR) Dr Cr Customer   75000 Bank 75000   Final Voucher Dr Cr Unrealized Gain 5000   Realized Gain   5000 The customer account is settled and a revenue of the currency difference amount is recorded as a Realized Gain. The brief summary of these transactions can be found in the Customer transactions (Customer Master  -> Customer -> Select Transactions from the top panel) The above was an example where there is a net gain from customer payment. Exactly equivalent accounting impacts will take place for other scenarios like vendor gain, vendor loss and customer loss as well. The below table shows the exactly the type of impact incurred for vendor/customer transactions for increasing or decreasing currency rate: Vendor Customer If Currency –> Increases If Currency –> Increases Then Vendor Account –> Increases (Cr) Then Customer Account –> Increases (Dr) Net result –> Loss (Dr) Net Result –> Gain (Cr) If Currency –> Decreases If Currency –> Decreases Then Vendor Account –> Decreases (Dr) Then Customer Account –> Decreases (Cr) Net result –> Gain (Cr) Net Result –> Loss (Dr) Now, what if the user makes the payment without running FCR? In that case, the system will directly impact the Realized Gain/Loss account for the currency variation amount against the vendor/customer. No Unrealized GL will be accounted. In conclusion, the process of running FCR is useful to determine the best time span for making payments in order to benefit from currency exchange rates.