At a Glance Company profile Infrastructure developer with legal entities in India, Southeast Asia and Europe Challenge Run all entities on one Business Central platform, managed from India, while meeting each country’s tax rules Question asked “Can we use only Indian localisation and handle the other countries’ taxes outside the system?” Options evaluated One production environment (India localisation and external tax) vs two production environments (local localisation) Recommendation Two production environments: one India, one Group (W1 base with a partner localisation) Key takeaway Localisation is an environment-level decision, and the hardest one to reverse after go-live Table of Contents Summary The Situation How Localisation Actually Works in Business Central Online Option 1: One Production Environment with External Tax Calculation Option 2: Two Production Environments with Local Localisation Side-by-Side Comparison The Cost Question Our Recommendation A Checklist Before You Decide Conclusion Frequently Asked Questions Summary Most multi-country ERP conversations start with modules: finance, procurement, projects, consolidation. But for groups operating across several tax jurisdictions, one of the earliest decisions matters more than any module choice. Where will each company live, and which localisation will it use? In Business Central online, that decision is easy to underestimate. It looks like a technical setup detail. In practice, it shapes your invoices, your tax returns, your intercompany design and your audit trail for as long as you run the system. Recently, one of our prospect, an infrastructure developer with entities in India, Southeast Asia and Europe, asked us a direct question: “Our finance team sits in India. Can we run every company on Indian localisation and handle the other countries’ taxes outside the system?” This blog walks through how we evaluated that question and what we recommended. The Situation The prospect was moving off separate accounting systems (a different package for each entity) with manual consolidation. Their requirements were clear: Several legal entities, with a holding entity planned above them. Different functional currencies and financial years. India runs April–March, while the other entities run January–December. Different reporting standards: Ind AS, IFRS and SFRS. Two-level consolidation. One central finance team in India managing all entities. Local tax compliance in each country: GST and e-invoicing in India, VAT in Europe, and GST with mandatory e-invoicing in Southeast Asia once registered. Running everything from India made Indian localisation feel like the natural default. The question was whether that default would hold up for the non-Indian entities. How Localisation Actually Works in Business Central Online Before comparing options, it helps to be clear on three points that often surprise finance teams. 1 Localisation is set per environment, not per company. Every company inside a Business Central online environment uses that environment’s localisation. That covers the tax engine, statutory reports and country-specific fields. You can create a Singapore or Cyprus company inside an India environment, but it will behave like an Indian company. 2 Microsoft doesn’t localise every country. Microsoft provides its own localisation for 21 countries, including India, Australia, New Zealand, the UK, the US and much of Western Europe. Many other markets, including Singapore and Cyprus, are served by partner localisation apps on AppSource, installed on Microsoft’s base version (W1). 3 Localisation is free, but environments aren’t. Microsoft doesn’t charge for localisation itself. A tenant includes one production environment. Every additional production environment needs an add-on subscription. Important Changing a company’s localisation after go-live means migrating it to a new environment, then re-testing and re-validating it. Getting this right at the design stage avoids expensive rework later. Option 1: One Production Environment with External Tax Calculation In this model, every company sits in a single environment on India localisation. Tax for the non-Indian entities is calculated in an external tool, and the amounts are brought into Business Central through an integration. What it involves: Switching off India-specific GST/TDS behaviour for the non-Indian companies. Custom invoice and credit-note layouts without India tax fields. An extension to post externally calculated tax amounts, so document totals match the original invoice. An API integration with the external tax tool, plus middleware and error logging. A custom e-invoicing integration (for example, Peppol / InvoiceNow) when it becomes mandatory. Pros One environment to administer. Simpler intercompany and consolidation, with no cross-environment setup. No additional production environment subscription. No partner localisation apps to license. Cons Tax returns are prepared outside Business Central, so they don’t tie directly to the ledger. More custom code to build, test and maintain through every Microsoft update. Two systems to reconcile every period. E-invoicing depends on an access-point provider supporting a non-standard setup. Higher audit exposure, and costly to reverse later. Option 2: Two Production Environments with Local Localisation In this model, the Indian entity sits in an India environment on Microsoft’s India localisation. All other entities sit in a Group environment on the W1 base, with a partner localisation app where needed and standard VAT configuration for the European entity. Intercompany and consolidation between the two environments use Business Central’s standard cross-environment features. Pros Each country’s tax is calculated and posted in Business Central. Local returns and audit files tie directly to the ledger. Invoices follow each country’s format, with no foreign tax fields. E-invoicing is supported through standard partner apps. Less custom code and lower upgrade risk. The same user licence works across both environments, so central finance in India is unaffected. Cons An additional production environment subscription. Partner localisation app subscriptions. Cross-environment intercompany needs experienced setup and testing. Two environments to administer (updates, sandboxes, permissions). Side-by-Side Comparison Area One Environment (India + external tax) Two Environments (local localisation) Production environments 1 2 Non-Indian tax Calculated outside BC, amounts integrated Calculated in BC Local tax returns Prepared outside BC Generated from BC Invoice compliance Custom layouts Standard local formats E-invoicing Custom integration Partner app Intercompany Same environment (simpler) Cross-environment (standard feature) Custom development Higher Lower Audit and upgrade risk Medium–High Low Reversibility Costly migration later Already correct The Cost Question At first glance, the single-environment option looks cheaper because it avoids the additional environment and the … Continue reading How a Multi-Country Infrastructure Group Evaluated One vs Two Production Environments in Dynamics 365 Business Central →

​ Summary An Australian commercial laundry and linen company already sent its quotes from Dynamics 365, with Approve and Reject buttons in the email. It worked, but the links never expired and could be clicked again and again, so a forwarded or months old email could still change a quote. We made every link single use and valid for 30 days. Customers still answer with one click, and the sales team can now trust the decision they see on the quote. In This Blog Why a reusable approval link is a quiet business risk What the customer sees, from email to confirmation What the sales team sees in Dynamics 365 How we went live without breaking quotes already sent When this approach is the right fit Table of Contents Summary→ Business Challenges→ What We Built→ How It Works→ Going Live Safely→ Impact→ Is This Right for You?→ Conclusion→ FAQ→ Get in Touch→ Business Challenges The quoting process itself was in good shape. Sales built the quote in Dynamics 365, generated the PDF and emailed it with two buttons. The customer clicked Approve or Reject and the answer landed on the quote. Nobody had to chase a reply or retype it. The weak spot was the link behind those buttons. It never changed and never expired, and anyone holding the email could use it. In practice that meant: A customer could approve a quote, then click Reject on the same email weeks later and quietly overwrite the decision. An email forwarded inside the customer’s business could be answered by someone who was never meant to decide. Quotes that had been revised and resent still had live buttons in the older emails. For a business that moves straight from an approved quote to a contract, the decision on the record has to be the real one. Before Links worked forever Any click could change the answer Old emails stayed live after a resend After Each link works once, for 30 days The first decision is final Only the newest email is live What We Built For the customer, almost nothing changed, which was the point. The email looks the same, with the quote attached and the two buttons underneath. There is still no login, no portal and no password to remember. The quote email with the PDF attached and one click Approve and Reject buttons. Captured from a test quote, names changed. One click records the decision and shows a short confirmation. When the quote is approved, the page tells the customer the contract is on its way. The confirmation the customer sees after approving. Captured from a test quote. What changed is everything after that first click. If a button is clicked again, the customer is told the quote is already approved and nothing on the record moves. If the link is older than 30 days, or a newer quote email has replaced it, a clear page asks them to contact their sales representative for a fresh link. Clicking the same link again changes nothing and says so plainly. Captured from a test quote. An expired or replaced link points the customer back to their sales contact. Inside Dynamics 365, the customer.s decision is saved straight onto the quote, along with when the link expires. That decision is what starts the contract process, so it now carries real weight. The test quote in Dynamics 365. The timeline confirms the quote document was sent for review and approval. Names changed. How It Works Everything runs on Dynamics 365 and Power Automate, which the client already had. No new apps and no new licences. Step oneSales sends the quoteFrom the quote, as before Step twoA unique link is issuedOne per email, valid for 30 days Step threeThe customer clicksThe link is checked before anything is saved Step fourDecision saved, link closedAny later click is politely turned away How a quote link moves from sent, to used or expired. Each time a quote is sent, Dynamics 365 stores a new private code and an expiry date on the quote, and that code is built into both buttons. When the customer clicks, the flow compares the code in the link with the one on the quote. Only a match within 30 days is accepted. Once the decision is saved, the code is marked as used, so the same link cannot be accepted again. Worth knowing before you start Resending a quote replaces the link, so customers should always act on the newest email. Agree the expiry period with sales up front: 30 days suited this client’s quoting cycle, but yours may be shorter. And make sure the expired page names someone the customer can actually contact. Going Live Safely The tricky part was not the new links. It was the quotes already sitting in customers’ inboxes, sent under the old process without a private code. Switching them off overnight would have turned a security improvement into a stream of confused customers. So those older emails keep working until each quote receives its first answer, and from then on the same single use rules apply. We built and tested in the client’s test environment first, then went live in production with test quotes sent only to our own team before any customer saw the change. Impact A decision you can trust. The answer on the quote is the customer’s first and final one, so contracts start from solid ground. No extra effort for customers. Still one click, still no login, on any phone or laptop. Old emails retire themselves. Revised quotes no longer leave live buttons behind. No new cost. Built on the Dynamics 365 and Power Automate licences the client already owned. Is This Right for You? There is more than one way to collect a customer’s yes. This is how we usually compare them with clients. This projectOne time email link Customer portal Electronic signature Customer effort One click, no login Sign in, then respond Open, review and sign Extra licences None Portal … Continue reading How an Australian Linen Company Made Quote Approvals Secure with One Time Links in Dynamics 365 →

Summary For Emirates Consortium, an Abu Dhabi-based diversified holding company already using Microsoft Dynamics 365 Business Central across multiple legal entities, intercompany accounting is a relevant process area. This article explores how standard intercompany functionality can simplify transactions between related companies. It covers intercompany partner relationships, customer and vendor links, and G/L account and dimension mappings. Using practical scenarios, we walk through a sales invoice raised in one company and received as a purchase invoice in another, as well as journal-based allocation of partial expenses. The walkthrough also shows how the Intercompany Outbox and Inbox support transaction review before posting, and highlights key reconciliation controls and limitations. Table of Contents Introduction The Business Problem The Solution Implementation and Process Walkthrough Limitations and Key Considerations Business Impact Frequently Asked Questions Conclusion Introduction Organizations operating through multiple legal entities often share resources, incur costs centrally, and recharge expenses to the company that actually benefits from them. Although these entities belong to the same business group, each company maintains its own accounting records, receivables, payables, and financial reporting. Emirates Consortium LLC is an Abu Dhabi-based diversified holding company with businesses across the UAE and Maldives. As highlighted in the Emirates Consortium customer success story, CloudFronts deployed Dynamics 365 Business Central across five legal entities to support core business processes. For organizations operating across several companies, intercompany recharges and cost allocation are important areas to assess when looking to reduce duplicate finance work. To explore these capabilities, consider two related companies, Gulf Aquaculture (GA) and Gulf Aquaculture Alliance (GAA). The walkthrough covers two practical routes: an intercompany sales invoice for a formal recharge and an intercompany general journal for direct cost allocation. It explains the setup, accounting impact, and important control points involved in both processes. Route A Intercompany Sales Invoice A formal recharge from GA, received in GAA as a purchase invoice. Route B Intercompany General Journal A direct allocation of part of a cost already recorded in GA. The Business Problem The finance team managed transactions for separate group companies, but some costs, such as consultancy, administration, payroll-related expenditure, and project-related operating expenses, were initially incurred or recorded in GA even when they partly or entirely related to GAA. For example, GA might receive an external vendor invoice for AED 10,000, of which AED 4,000 is attributable to GAA. Without a standard cross-company workflow, staff must determine the chargeable amount, prepare a corresponding transaction in the second company, and verify that the two sets of books agree. 10,000 AED external vendor invoice recorded in GA 4,000 AED attributable to GAA 6,000 AED that remains GA’s own cost Handling this manually created five gaps: 01 Manual Re-Entry Re-entering transactions increased the risk of inconsistent amounts, descriptions, or account classifications between companies. 02 Hidden Costs The receiving company needed visibility into its own project and operating expenses rather than having those costs remain embedded in GA. 03 Limited Control Finance required control over which transactions were sent, accepted, and posted, particularly for higher-value recharges. 04 Different Account Structures The chart of accounts and dimensions needed to translate correctly when the two companies used different codes or reporting structures. 05 Month-End Reconciliation Intercompany balances needed to be traceable and reconcilable at month-end. Business Objective Record the charge once in the initiating company, communicate it through Business Central, and let the receiving company review and post the corresponding entry in its own books. The Solution The proposed approach used standard Business Central intercompany functionality rather than a separate custom integration. Both companies were configured as intercompany partners, with mapped accounts and dimensions to support the exchange of transactions. 1. Establishing the Intercompany Relationship Each participating Business Central company needs its own Intercompany Setup and a unique IC Partner Code. The other company is then added as an intercompany partner with an appropriate transfer method. For a partnership inside the same Business Central environment, direct company-to-company transfer can be used where supported by the configured environment. 2. Connecting Customers and Vendors In GA, GAA is represented by an intercompany customer for billing. In GAA, GA is represented by an intercompany vendor for recording the payable. Assigning the relevant IC Partner Code on the customer and vendor records connects the commercial documents to the receiving company. In GA Customer card GAA as an Intercompany Customer Used to bill GAA. The IC Partner Code links the invoice to GAA. In GAA Vendor card GA as an Intercompany Vendor Used to record the payable to GA. The IC Partner Code links it back to GA. 3. Mapping the Intercompany Chart of Accounts Business Central uses a shared intercompany chart of accounts as the language between companies. Each company maps its own G/L accounts to the intercompany accounts and maps incoming intercompany accounts back to its local G/L accounts. When account numbering differs between companies, these mappings are essential. During the walkthrough, the team reviewed how a sales invoice line could carry an IC Partner Reference so that the receiving company would recognize the appropriate expense account. Account mapping in both directions was especially important: an account existing in one company does not guarantee that the other company can post it. 4. Preserving Dimensions and Project Context Intercompany dimensions can transmit reporting context such as Department, Project, or Cost Centre when corresponding dimension codes and values are set up and mapped. The accounting team should confirm that the receiving company’s dimension values accurately represent the destination project or department. 5. Choosing the Appropriate Transaction Route Business Requirement Recommended Standard Route Formal charge for services or reimbursable costs GA intercompany Sales Invoice → GAA Purchase Invoice Partial allocation of an expense already recorded in GA Intercompany General Journal → corresponding journal in GAA Direct allocation while registering an external vendor invoice Purchase Invoice cost-allocation fields for IC Partner, where applicable and tested Correction of an earlier intercompany charge Appropriate credit memo or reversing journal, reviewed in both companies The following walkthrough focuses on the first two routes: intercompany invoices and intercompany … Continue reading How an Abu Dhabi-Based Diversified Holding Company Simplified Intercompany Transactions in Dynamics 365 Business Central →

Summary Connecting Dynamics 365 Project Operations with Business Central creates a continuous data journey from project planning and execution to financial visibility. Project and task information, planning lines, time, materials, expenses, billable values, and invoices must retain their identity and meaning as they move between systems. This implementation focuses on preserving those relationships so that Budget, Actual, Billable, and Invoiced values remain traceable and meaningful throughout the project lifecycle. The result is an integration that does more than synchronize records: it creates a reliable data story that supports project operations, ERP processes, financial analysis, and decision-making. Table of Contents Why Project Data Needs a Journey The Data Journey Entity-to-Entity Mapping Planning Lines Budget vs. Actual vs. Billable vs. Invoiced Execution and Project Journals From Activity to Invoice The Analytics View Implementation Lessons Conclusion The Project Does Not Live in One System Project Operations is where teams plan and manage project work. Business Central is where the project becomes part of an ERP financial workflow. The interesting part is the space between them. When the same customer, project, task, resource, or transaction crosses that boundary, the integration has to preserve more than a name. It has to preserve relationships and translate the source record into the target system’s business model. The Engineering Question “Did the record sync?” is only the first question. “Does the record still mean the same thing?” is the engineering question. CRM Project Operations Where the Project Is Planned Customer, project, tasks, resources, estimates, time, and project activity are planned and managed here. ERP Business Central Where the Project Becomes Financial Project tasks, planning lines, journals, invoices, and financial visibility form the ERP financial structure. CRM side Figure 1: A Project Operations project with stages, customer, dates, estimates, and project context. ERP side Figure 2: The corresponding project structure in Business Central. A Different Way to Look at the Integration Think of It as a Data Pipeline Source entities become mapped entities, mapped entities become ERP records, and ERP records eventually become transactions and financial metrics. How a record moves between the two systems Project Operations projects · tasks · resources → Mapping Layer identity · transformation → Business Central projects · planning lines 01 Plan Estimates, tasks, resources, and planned quantities describe what the project is expected to consume. 02 Execute Time, materials, and expenses create operational evidence of what happened. 03 Bill Billable value moves toward invoicing, turning project activity into commercial output. Entity-to-Entity Mapping Is Where Meaning Gets Preserved One of the most important parts of a Project Operations to Business Central integration is deciding what a source entity becomes in Business Central. The mapping is effectively a semantic contract. Project Operations Business Central Why It Matters Account (Customer) Customer Customer identity must remain consistent across systems Project msdyn_project Project / Job The project becomes the parent financial structure Project Task msdyn_projecttask Project Task / Job Task Task identity is required for planning and transaction attribution Estimate msdyn_estimateline Job Planning Line Planning becomes a structured Business Central financial planning record Time Entry msdyn_timeentry Project Journal Recorded effort can become project usage Figure 3: Account data flowing into Business Central as a customer, carrying its identity across the boundary. Planning Lines Are the Semantic Bridge Planning lines sit at the point where a project plan starts becoming an ERP financial model. In Business Central, planning lines can represent planned cost, billable value, or both, depending on how they are configured. That makes them especially important when explaining the transition from “what we intend to do” to “what the ERP expects this project to cost or generate.” Quantity How much work, material, or resource usage is expected? Unit Cost / Price What cost or commercial rate is associated with the planned quantity? Total Cost / Price The planning line turns quantity and rates into project-level financial expectations. CRM side Figure 4: The work breakdown structure decomposes project work into manageable tasks. ERP side Figure 5: Resource assignments become structured planning lines in Business Central. The Four Numbers People Confuse Most These values answer different questions. Treating them as interchangeable is one of the fastest ways to misread a project dashboard. 01 Budget: What Did We Expect to Spend? Budget represents planned cost. It is a planning value, not proof that the cost has already occurred. 02 Actual: What Cost Was Recorded? Actual (usage) cost is tied to execution and recorded project usage. A blank actual does not mean the budget disappeared; it means no actual usage has been recorded in that context. 03 Billable: What Value Can Be Charged? Billable represents chargeable project value according to the project’s planning and billing configuration. 04 Invoiced: What Has Actually Been Billed? Invoiced is downstream of billable value. A project can have billable value before the corresponding amount has been invoiced. The Simplest Mental Model Budget → Actual answers the cost question. Billable → Invoiced answers the revenue and billing question. Figure 6: Project budgeting concepts in Project Operations (source: Microsoft Learn). Execution Creates the Evidence Once the project moves from planning into execution, operational records begin to tell the story of what actually happened. Time entries, material usage, and expenses are examples of records that contribute to project actuals and downstream ERP transactions. What feeds the project journal Time hours worked + Materials items consumed + Expenses project spend → Project Journal CRM side Figure 7: Time entries recorded against projects and tasks. ERP side Figure 8: Approved time entries represented in the Business Central project journal. Figure 9: Material usage follows the same project-to-ERP transaction path. Engineering Insight An integration should be traceable backwards. If a number appears in an ERP report, you should be able to explain which transaction produced it and which project and task it belongs to. From Project Activity to Invoice The final part of the journey is commercial. Billable project data eventually feeds invoicing, creating a visible chain from planned work to customer-facing financial output. 01 Project Activity Time, materials, expenses, and … Continue reading From Project Operations to Business Central: Following the Data Behind Project Financials →

Summary For a Maldives-based marine services firm running Microsoft Dynamics 365 Business Central across multiple operating sites, item journals are used to record consumption and disposal of inventory such as diving and water sports equipment, consumables, and spares. The standard item journal does not stop a user from consuming or disposing more than is physically available at the selected location, because the item lookup and the Inventory figure reflect stock across all locations. In this implementation, we restricted item visibility and quantity validation to the location selected on the journal line. Users must select the location first, the item lookup shows only items with stock at that location, and the quantity is validated both when the line is entered and again at posting. We also carried the location onto the Item Journal Batch so that approval workflows can be routed per location. Table of Contents Introduction Understanding the Business Requirement The Challenge with Standard Item Journals Filtering the Lookup vs. Validating the Line Designing the Solution Filtering the Item Lookup by Location Validating Quantity at Entry and Posting Routing Approvals by Location Implementation Approach Business Impact Frequently Asked Questions Conclusion Introduction Many organizations running Microsoft Dynamics 365 Business Central hold the same items across several locations: properties, stores, warehouses, or project sites. Day-to-day consumption and disposal of that stock is usually recorded through item journals. Consider a storekeeper who opens the item journal to record the use of cleaning supplies. Business Central tells her one thing; her storeroom tells her another. 200 Units shown in Business Central 60 Units on her own shelf 140 Units at other locations Without additional controls, nothing prevents her from posting 100 units from her location. The journal accepts it, the location goes negative, and the difference only surfaces during stock counts or month-end reconciliation. This was the challenge for a Maldives-based marine services firm we worked with. Its sites are spread across separate islands, so equipment and consumables held at one site cannot simply be used at another. We addressed this with one rule enforced at every step: The Rule A user can only consume or dispose of what is physically available at the location they selected. Understanding the Business Requirement Before writing any code, we agreed the expected behavior with the client as concrete scenarios. Each scenario later became a test case for user acceptance testing. Scenario 1 Item Stocked Across All Locations Cleaning concentrate. User selects Location A. Location A60 Other locations140 Company total200 Shows 60 available. Entering 100 is blocked. Scenario 2 Item Available at Several Locations Snorkel mask. User selects Location A. Location A30 Location B5 Location C21 Location D10 Shows 30 available. Other locations are ignored. Scenario 3 No Stock at the Selected Location Kids’ snorkel set. User selects Location D. Location A10 Location B0 Location C0 Location D0 Not available. Consumption and disposal are blocked. From these scenarios, we derived three key requirements: Show only the items and quantities available at the selected location. Prevent any consumption or disposal quantity greater than the location’s available stock. Route approvals to the person responsible for that location. The Challenge with Standard Item Journals Standard Business Central treats the item journal as a general-purpose adjustment tool, and it trusts the user. For businesses with stock spread across sites, three gaps follow from that. 01 Lookup Shows Company-Wide Stock The Inventory figure on the Item List is the total across all locations unless a location filter is applied. A user sees 200 when only 60 is on their shelf. 02 Location Is Just Another Field Users can select the item first and the location later, or leave it blank, so the system has no location context when the item is chosen. 03 Quantity Isn’t Checked by Location Prevent Negative Inventory is often switched off, only triggers at posting, and gives a storekeeper little guidance. Figure 1: The standard item lookup shows total inventory across all locations, not the stock at the user’s location. Key Design Consideration Location needed to be the starting point of every consumption and disposal line, not an optional detail added afterwards. Filtering the Lookup vs. Validating the Line The first instinct is to filter the item lookup by location. That is useful, but it is not a control on its own. Guides Lookup Filtering Points the user to the right items. It does nothing when someone types an item number directly, pastes lines, or uses Edit in Excel. Enforces Validation Runs whenever the field changes, however the value arrives. Every rule shown in the lookup needs a matching check in table validation and at posting. How a consumption or disposal line moves through the checks Select Location → Item Lookup at Location → Entry Check → Posting Check → Line Posts Designing the Solution We reduced the requirement to four rules that apply to every consumption and disposal line. 1 Location First The user must select the Usage Location Code before the Item No. field becomes editable. The location carries over to the next new line. 2 Show Only What Is There The item lookup lists only items with stock above zero at the selected location, with that location’s quantity. 3 Never More Than Is There The quantity cannot exceed available stock at the location, after subtracting other unposted lines for the same item. 4 Check Again at Posting Stock can change between entering and posting a line, so the same rule runs again just before each line posts. Figure 2: Usage Location Code must be selected before the Item No. field becomes editable. Together, these rules form three layers of control: Layer 1 · Lookup Guides the user to items in stock at the selected location. Layer 2 · Entry Check Blocks over-consumption as soon as the line is entered. Layer 3 · Posting Check Confirms availability against live stock before posting. Filtering the Item Lookup by Location Business Central already calculates stock per location. The Inventory field on the Item table is a FlowField that … Continue reading Location-Based Item Based Visibility in Business Central for a Maldives-Based Marine Services Firm →

Summary Project-based organizations often manage project delivery in Microsoft Dynamics 365 Project Operations while relying on Microsoft Dynamics 365 Business Central for finance, purchasing, inventory, and accounting. Without a connected process, project teams and finance teams can end up working with different versions of the same information. CloudFronts built an integration between Project Operations and Business Central using Dataverse plugins. Instead of relying on users to manually recreate records, the integration responds to important Project Operations events and sends the relevant data to Business Central through web services. It covers customers, projects, timesheets, expenses, invoices, and inventory availability, writes the Business Central identifier back to the originating Project Operations record, and captures failed transactions in an Error Log for troubleshooting. Table of Contents The Project Integration Challenge Our Integration Architecture Keeping Project Customers in Sync Connecting Projects to Business Central Synchronizing Timesheets Moving Project Expenses into Finance Connecting Project Invoices End-to-End Project Integration Flow Business Benefits Key Implementation Considerations Frequently Asked Questions Conclusion About the Example in This Post To show how the integration behaves end to end, the screenshots use a sample customer, Westview Ltd, and its project, Westview-Project-003. These are sandbox records used purely to demonstrate the data flow between Project Operations and Business Central. The Project Integration Challenge Project-based businesses have a unique challenge: the people delivering the project and the people managing its financial impact often work in different systems. Project Operations can be the place where project teams manage customers, projects, resources, tasks, time, expenses, and project billing. Business Central, meanwhile, can be responsible for financial management, purchasing, inventory, and other ERP processes. When these systems are not connected, the same project information may have to be entered more than once. A project manager may record time in Project Operations while finance needs the same information in Business Central. A project invoice may be created in one system while the corresponding financial information needs to be reflected in another. The Core Problem Project teams need to work in the system designed for project delivery, while finance needs accurate and timely information in the ERP. Manual re-entry creates extra effort, delays, and opportunities for data inconsistency. The objective of the integration was therefore not simply to move records between two applications. It was to connect the project lifecycle with the corresponding Business Central processes. Our Integration Architecture The integration uses Dataverse plugins as the event-driven layer connecting Project Operations with Business Central. A Dataverse plugin is a piece of C# code that runs when a Dataverse record is created, updated, or otherwise processed. This provides an opportunity to respond to project-related events and send the relevant information to Business Central. High-Level Flow A user creates or updates a project-related record in Project Operations. The corresponding Dataverse event triggers the plugin. The plugin reads the required information from Dataverse. The data is transformed into the structure required by Business Central. The plugin calls the relevant Business Central web service. Business Central creates or updates the corresponding record. The Business Central identifier is written back to the Project Operations record where required. If the request fails, the integration captures the error and the data involved in an Error Log. Why an Event-Driven Approach? The integration reacts when project information changes, instead of depending on users to remember when and where the same information must be entered. Figure 1: High-level architecture of the Project Operations to Business Central integration. Keeping Project Customers in Sync Customers are a fundamental dependency for project processes. Before project transactions can be represented correctly in Business Central, the corresponding customer needs to exist there. When a customer is created or processed in Project Operations, the integration sends the relevant customer information to Business Central. What the Integration Achieves 01 Create or Sync Creates or synchronizes the customer in Business Central. 02 Map the Fields Uses the appropriate source-to-target field mapping. 03 Capture the Number Captures the Business Central customer number. 04 Write It Back Writes the Business Central identifier back to the originating record where required. This creates an important link between the two systems. The Project Operations record retains the Business Central number, so users do not have to search manually for the corresponding ERP record. In our example, Westview Ltd is created as an account in Project Operations. The integration synchronizes it to Business Central and writes the resulting Business Central customer number (C00280) back onto the Project Operations record. Figure 2: Westview Ltd in Project Operations, with the Business Central customer number (C00280) written back to the int_sourceid field. Figure 3: The corresponding Westview Ltd customer record (C00280) synchronized into Business Central. Connecting Projects to Business Central Customer synchronization is only the beginning. The central object in a project-based integration is the project itself. When a project is created or prepared for synchronization, the integration retrieves the project information required by Business Central and creates the corresponding project record. It then maintains the relationship between the Project Operations project and the Business Central project using the relevant identifiers. Why Project Identifiers Matter A Project Operations record may contain Dataverse identifiers and lookup references, while Business Central works with its own project numbers. These identifiers cannot simply be assumed to be interchangeable. The integration needs to resolve the correct project identifier and use it when subsequent project-related transactions are sent to Business Central. Project Integration Principle Synchronizing a project is not only about copying project fields. It establishes the reference that later transactions, such as time, expenses, materials, and billing, use to reach the correct Business Central project. Continuing the example, Westview-Project-003 is created under Westview Ltd in Project Operations. The integration creates the matching project in Business Central and writes the Business Central project number (PR00340) back to the int_sourceid field on the Project Operations record. Figure 4: Westview-Project-003 in Project Operations, with the Business Central project number (PR00340) written back to int_sourceid. Figure 5: The corresponding Project Card (PR00340) for Westview-Project-003 in Business Central. Synchronizing Timesheets Time is one … Continue reading How to Integrate Dynamics 365 Project Operations with Business Central Using Dataverse →

At a Glance A client in Abu Dhabi discovered more than 400 posted G/L entries with incorrect dimension values. Using Dimension Correction in Microsoft Dynamics 365 Business Central, the finance team was able to correct the dimension values in bulk without creating reversal or adjustment entries. The corrections could be validated, audited, reviewed, and undone, providing a controlled approach to fixing posted transactions. However, it is important to note that Dimension Correction applies to G/L entries only; related sub-ledger entries retain their original dimensions. Table of Contents Introduction Why Dimension Errors Happen in the First Place What Dimension Correction Actually Does Setting Up Before the First Correction Step 1: Starting the Correction from the Ledger Step 2: Selecting Entries in Bulk Step 3: Defining the Dimension Changes Step 4: Validating Before You Run Step 5: Running the Correction Step 6: Reviewing, Undoing and Auditing A Note on Cost Accounting The Outcome Best Practices We Recommend Conclusion Frequently Asked Questions About the Author Introduction Dimensions are what turn a general ledger from a list of numbers into something management can actually use. A single expense posting tells you how much was spent; the dimensions on that posting tell you which department spent it, on which project, at which location. When dimensions are right, reports by cost centre, business unit or project take seconds to produce. When they are wrong, every one of those reports quietly becomes unreliable. That was the situation one of our clients in Abu Dhabi found themselves in. During routine month-end review, their finance team noticed that a large group of posted transactions carried the wrong dimension values. Some entries were tagged to the wrong department, others to the wrong project, and a few had no value at all where one was expected. By the time the pattern was traced, more than 400 general ledger entries were affected. Reversing and re-posting each transaction was not an option. It would have doubled the number of entries in the ledger, cluttered the audit trail and taken days of effort. Editing entries one at a time was equally impractical. Instead, we used the Dimension Correction feature in Microsoft Dynamics 365 Business Central to fix all of them in a controlled, bulk operation, without touching the amounts or the accounts. This blog walks through how the feature works, how we applied it for this client, and what to keep in mind before you run a correction in your own environment. Why Dimension Errors Happen in the First Place In our experience, incorrect dimensions rarely come from a single cause. For this client, the errors came from a mix of everyday situations that most finance teams will recognize: 1. Default dimensions not updated after an internal restructuring, so new transactions kept inheriting the old department code. 2. Manual journal entries where users picked a similar-looking value from the lookup list. 3. Recurring journals that were copied forward month after month with an outdated project code. 4. Imported data from a spreadsheet where the dimension column was shifted by one row. None of these errors affected the trial balance. The debits and credits were correct and the accounts were correct. What was wrong was the analytical layer on top, which meant that department-wise P&L and project cost reports no longer matched reality. What Dimension Correction Actually Does Dimension Correction lets an authorized user change the dimension values on general ledger entries that have already been posted. It does this without creating new journal lines, reversals or adjustment postings. The amounts, dates, document numbers and G/L accounts stay exactly as they were; only the dimension set linked to each entry is updated. Every correction is recorded as its own document with a description, a status and a list of the entries it touched. That means auditors and finance managers can always see what was changed, when, and why. Important limitation The correction applies to G/L entries only. Related sub-ledger entries, such as customer, vendor, item or fixed asset ledger entries, keep their original dimensions. Since the purpose of the feature is accurate financial reporting, this is by design, but it is worth communicating to anyone who reports from sub-ledgers. Setting Up Before the First Correction Before our client’s finance team ran anything, we put two controls in place. 1. Decide who can correct dimensions Access to the feature is governed by the D365 DIM CORRECTION permission set. We assigned it only to the finance controller and one senior accountant. Users with this permission can create, run and undo corrections, so it should not be handed out broadly. 2. Protect dimensions that should never change On the Dimension Correction Settings page, you can list dimensions that are blocked from correction. For this client, we blocked the dimension used for statutory entity reporting, since any change there needed a formal adjustment rather than a re-tag. Step 1: Starting the Correction from the Ledger A correction can be started from two places: 1. General Ledger Entries page, using the Correct Dimensions action. This is the most flexible starting point when the affected entries are spread across many postings. 2. G/L Registers page, by selecting a register and choosing Correct Dimensions. This pre-loads all entries from that register and is useful when a single batch posting went wrong. Because the client’s 400+ entries came from different journals and dates, we started from the General Ledger Entries page. The first thing we filled in was the Description field, with a note explaining the reason for the change and a reference to the internal approval. It takes ten seconds and saves a lot of questions six months later. General Ledger Entries page showing the Correct Dimensions action. Step 2: Selecting Entries in Bulk This is where the feature really earns its place. Instead of picking entries one by one, the Selected Ledger Entries FastTab offers several ways to build the list: Option How we used it Add by Filter Filtered on G/L account range and posting date range to pull … Continue reading How an Abu Dhabi-Based Diversified Holding Company Corrected Mis-Tagged Ledger Entries in Dynamics 365 Business Central →

Summary This solution is being implemented initially for the Chart of Accounts of an Emirates-based firm , where significant updates are required across the existing G/L Account master. The objective is to provide Finance users with a simpler and more familiar way to review and maintain supported records through Excel, reducing the dependency on technical users for routine maintenance activities. Although the current implementation focuses on the Chart of Accounts, the approach is not limited to G/L Accounts and can be extended to other supported master data, such as Customers, Vendors, Items, and similar records. By providing an Excel-based alternative for suitable maintenance scenarios, the solution reduces the need to use Configuration Packages for every routine update while allowing technical teams to focus on complex development, integrations, automation, and customization activities. Table of Contents Introduction Understanding the Business Requirement The Traditional Approach The Business Problem The Excel-Based Solution Using Excel Integration Selecting the Required G/L Accounts Reviewing Existing Data Updating Supported Fields Publishing Changes Verifying the Changes Implementation Approach Moving Bulk Maintenance Toward Functional Users Business Impact Important Considerations Frequently Asked Questions Conclusion Introduction The Chart of Accounts is one of the core components of financial management in Microsoft Dynamics 365 Business Central. As part of the current implementation for an Emirates-based firm, significant updates are required to the existing Chart of Accounts to align the financial structure with the organization’s evolving reporting, accounting, and operational requirements. Since the required changes involve a large number of G/L Accounts, updating each account individually within Business Central would be repetitive and time-consuming. The volume of changes creates a requirement for a more efficient approach that allows multiple existing records to be reviewed and updated in a structured manner. Traditionally, Configuration Packages can be used to perform bulk data updates in Business Central. While this provides a powerful mechanism for data migration and bulk maintenance, routine updates may still require technical involvement and additional configuration steps. For the current Chart of Accounts requirement, the objective is to provide Finance users with a simpler and more familiar method for making supported bulk changes. The Key Question: Can Finance users efficiently review and update a large number of G/L Accounts through a familiar Excel-based interface, while reducing the need for technical assistance for routine bulk maintenance activities? To address this requirement, the proposed approach uses the Microsoft Dynamics 365 Business Central Excel integration for supported bulk maintenance activities. Although the initial implementation is focused on the Chart of Accounts due to the significant updates required for the Emirates-based firm, the same approach can also be applied to other supported master data, such as Customers, Vendors, Items, and other relevant records, where similar bulk maintenance requirements arise. Understanding the Business Requirement During the implementation, the consultant was faced with a practical challenge: the Finance team needed to make a significant number of changes to the existing Chart of Accounts, but updating each G/L Account individually in Business Central would require considerable manual effort. The consultant also needed a solution that Finance users could work with directly, without having to depend on the technical team for every routine change. The Excel integration provided a way to address this issue by allowing the consultant to work with the relevant G/L Account data in a familiar spreadsheet environment. Instead of opening and modifying accounts one by one, the required records could be brought into Excel, reviewed together, and the necessary values could be prepared or updated in bulk. This made the large-scale Chart of Accounts maintenance activity more manageable and significantly reduced repetitive manual work. How the Requirement Was Resolved: The consultant can use the Business Central Excel integration to provide Finance users with a structured way to work with supported G/L Account data in bulk. This allows multiple records to be reviewed and updated through Excel rather than requiring individual changes within Business Central for every account. This approach also addressed the dependency between the Finance and technical teams. Finance users can handle suitable routine master-data maintenance themselves, while the technical team remains available for activities that genuinely require technical expertise, such as complex customizations, integrations, automation, troubleshooting, and development. Although the immediate problem was related to the Chart of Accounts, the solution is not limited to G/L Accounts. The same concept can be applied wherever Business Central supports the relevant Excel-based maintenance capability, including other master data such as Customers, Vendors, Items, and similar records. This makes the approach useful beyond the immediate implementation and provides a repeatable method for handling future bulk maintenance requirements. The Traditional Approach Before considering the Excel-based approach, the consultant could use Configuration Packages to perform bulk updates to the Chart of Accounts. Configuration Packages are a standard and powerful Business Central capability for importing, exporting, and managing data across Business Central tables and remain particularly useful for data migration, initial configuration, and structured data-import scenarios. However, for the current requirement, the Finance team needed to make a significant number of changes to existing G/L Accounts. Using a Configuration Package for every such change could require additional preparation and involvement from a technical or experienced Business Central user. This created an additional dependency for what was essentially a routine master-data maintenance activity. The consultant therefore had to consider not only how the data could be updated in bulk, but also how the process could be made easier for the Finance team while maintaining appropriate control over the data. Finance Identifies Changes → Prepare Update Data → Technical Assistance → Configure Package → Import & Validate → Finance Verification This approach works well when there is a genuine requirement for structured data migration or when multiple related tables and fields need to be handled together. However, for repetitive updates to existing master records, it can result in additional steps that are not always necessary for the Finance user’s immediate requirement. The objective, therefore, was not to replace Configuration Packages altogether. Instead, the consultant identified an opportunity to use the Business Central Excel … Continue reading How an Abu Dhabi-Based Diversified Holding Company Simplified Master Data Maintenance in Dynamics 365 Business Central Using Excel →

Summary A home loan bank in the Maldives came to us needing legal, customer-facing reports for loan statements and overdue notices that had to reflect exact facility figures while matching the bank’s letterhead and legal wording. Traditional RDLC-based report development would have created significant IT dependency and delay for a document like this. Instead, our team used Word-based report layouts in Microsoft Dynamics 365 Business Central, which let us design the legal notice in a familiar document tool while Business Central handled populating it with live facility and customer data. We mapped the bank’s Business Central fields into a Word template, tested it against real facility scenarios, and delivered a working legal report in approximately two days, which is a turnaround that would traditionally take weeks with RDLC. This article walks through how we approached the build, using a sanitized sample report in place of the client’s confidential documents, and explains when we’d recommend Word over RDLC for a bank’s reporting needs. Table of Contents Introduction The Problem: IT Bottlenecks and Delayed Customer Documents The Word-Based Reporting Solution 3.1 How the Word-Based Approach Works 3.2 Creating the Word Template 3.3 Mapping Business Central Fields 3.4 Testing and Delivering the Report Sample Walkthrough: The Legal Report We Built Word Report vs. RDLC Report Time and Effort Comparison Why Banking Teams Benefit from Word Reports What Types of Banking Documents Work Best? Business Benefits When RDLC Is Still the Better Choice FAQs Conclusion About the Author Introduction Legal, customer-facing documents are one of the most sensitive parts of any lending business. A home loan bank in the Maldives came to us needing exactly this kind of document: a legal report covering a loan statement and overdue notice, which had to reflect exact facility figures, carry the correct legal clauses, and match the bank’s letterhead, all while pulling live data straight out of Business Central. Producing a document like this inside Microsoft Dynamics 365 Business Central can easily turn into a multi-week project if it’s built the traditional way. RDLC-based reporting usually means a developer has to build and maintain the report layout, write or modify code, configure data sources, and run several rounds of testing before the document is ready to go out to a customer. For a fairly standard legal document, like a loan statement or overdue notice, that kind of timeline is hard to justify. So instead of taking the client down the RDLC route, we proposed another option: Word-based report layouts. Word templates let us design the layout of the legal report in a tool the bank’s own team could later maintain, while Business Central handled populating it with the correct facility and customer data. The key idea: We designed the legal report’s layout and wording in Word, and let Business Central handle pulling in the correct facility data, so the client wasn’t locked into a developer for every future change. This article walks through how we built it, using a sanitized sample report in place of the client’s confidential documents, and explains how a report that would traditionally take weeks of RDLC development was designed, mapped, and delivered in approximately two days using a Word-based approach. The Problem: IT Bottlenecks and Delayed Customer Documents When the client first came to us, their existing experience with reporting was the same one many banks run into: a dependency between operations teams and technical teams that turns a simple document request into a long wait. The kind of request that used to happen internally looked something like this: “Hey, can we get a loan statement that shows the customer’s outstanding EMI, fines, and facility balance in one clean document?” “Sure, I’ll put in a ticket with IT.” [Two weeks later…] “The statement is almost done. It should be ready in another couple of weeks.” [Four weeks later…] “It’s finally here. Wait… the layout doesn’t match our branch letterhead format.” This kind of situation can happen when a relatively standard customer document becomes dependent on development resources. Why Do These Delays Happen? RDLC report layouts can require specialized development knowledge. Developers need time to configure data sources and implement the required reporting logic. Testing and troubleshooting can add additional development cycles. Small formatting changes such as a different overdue clause or a revised disclaimer may require technical assistance. Future modifications can place the document back into the development queue. Branch or collections staff may resort to manual, Word- or Excel-based workarounds while waiting for the official document. The result is a disconnect between the people who understand exactly what a legal notice or statement needs to say and the people responsible for implementing it in the system. The question we asked the client: What if your own operations or collections team could design and maintain these legal documents, using a tool they already know instead of relying on a developer for every change? The Word-Based Reporting Solution Microsoft Word was already familiar to the bank’s operations staff, so we proposed taking advantage of that. Business Central supports using Word templates directly as report layouts, which meant we didn’t need to build the legal report’s presentation through RDLC at all. Instead of developing the entire document presentation through RDLC, we designed the layout directly in Word and mapped Business Central’s available facility and customer data to the appropriate fields within that template. The solution: We used Word for the legal report’s presentation and Business Central for the facility data behind it. This separated document design from complex layout development and gave the client’s operations team greater control over formatting, tone, and compliance wording going forward. How We Approached the Build Our overall process was straightforward: Design the legal report layout using Microsoft Word. Add the required data fields to the Word template. Map those fields to the appropriate Business Central data. Run the report and let Business Central populate the template. Review the generated document with the client and adjust the layout where needed. The important distinction is that the document’s visual … Continue reading How We Built Legal Reports in Word on Business Central for a Home Loan Bank in the Maldives →

Summary In Business Central, users may need to view relevant purchase invoice details directly from General Ledger Entries for better transaction visibility and traceability. This enhancement was implemented based on requirements identified across multiple Business Central implementations, including projects for a leading UAE-based consortium and a financial institution in the Maldives. The solution enables purchase invoice details to be automatically captured against relevant General Ledger Entries for new transactions, while also providing an option to update previously posted entries. This helps finance users quickly identify the related invoice information without having to navigate through multiple pages or documents. Related Case Studies: Emirates Consortium – Customer Success HDFC PLC – D365 Business Central Integrated with Loan Management Table of Contents Introduction Understanding the Business Requirement The Challenge with Standard G/L Entry Descriptions Displaying vs. Storing the Description Designing the Solution Updating Historical G/L Entries Maintaining the Description for New Entries Implementation Approach Business Impact Frequently Asked Questions Conclusion Introduction In day-to-day financial operations, users often need to trace General Ledger Entries back to the original purchase transactions for verification, reconciliation, and reporting purposes. However, the standard General Ledger view may not always provide enough contextual information to quickly identify the details of the related purchase invoice. Based on requirements identified across multiple Business Central implementations, including projects for a leading UAE-based consortium and a financial institution operating in the Maldives, an enhancement was introduced to make relevant purchase invoice details available directly within General Ledger Entries. The enhancement improves transaction visibility by capturing the relevant purchase invoice description against the General Ledger Entry. For newly posted transactions, the information can be populated automatically, while previously posted entries can be updated through a dedicated action. This approach reduces the need for users to navigate between General Ledger Entries and posted purchase invoices, making financial review and transaction tracing more convenient and efficient. Understanding the Business Requirement From a Finance user’s perspective, the requirement was straightforward: When a user reviews a G/L Entry, the Description should provide meaningful information about the transaction. The requirement needed to work for both existing historical entries and transactions posted after the customization was introduced. 1. Historical G/L Entries Business Central may already contain a significant number of posted G/L Entries. These historical records also needed to have the enhanced description populated. Updating these entries individually would not be practical. Therefore, the solution needed to provide a controlled way to update existing G/L Entries in bulk. 2. New G/L Entries For future transactions, the description should be populated automatically during the posting process so that users do not have to manually update the G/L Entry after posting. This resulted in two key requirements: Provide a mechanism to populate descriptions for historical G/L Entries. Automatically maintain the description for newly created G/L Entries. The Challenge with Standard G/L Entry Descriptions The first question during the design was whether the required description could simply be calculated when the G/L Entry page was opened. At the page level, a value can be calculated dynamically based on related information. This approach can be useful when the requirement is simply to display additional information to the user. However, there is an important distinction between displaying a calculated value and storing that value in the underlying G/L Entry record. A page-level calculated value does not automatically become part of the underlying G/L Entry data. Therefore, although a user may see the expected description on the page, the value may not be available in the same way for other processes that directly consume the G/L Entry data. Key Design Consideration The requirement was not only to display a meaningful description. The description needed to be persisted against the G/L Entry record. Displaying vs. Storing the Description This distinction became an important part of the solution design. 1. Page-Level Calculation A page-level calculation is useful when the requirement is simply: “Show this information to the user.” The value can be generated when the page is opened without modifying the underlying G/L Entry record. 2. Persisted G/L Entry Description For this requirement, the description needed to become part of the actual G/L Entry data. The solution therefore stores the generated description directly against the G/L Entry. G/L Entry → Determine Transaction Information → Generate Description → Store in G/L Entry This approach ensures that the description remains available after the page is closed and can be consumed by other Business Central processes that use the G/L Entry record. Designing the Solution The solution was designed around two scenarios: historical G/L Entries and newly created G/L Entries. 1. Historical G/L Entries A dedicated action is provided to populate the enhanced description for existing G/L Entries. This allows Finance users or authorized administrators to update historical records without having to process each entry individually. 2. Newly Created G/L Entries For newly posted transactions, the description is maintained as part of the G/L Entry creation process. This means that the enhancement does not depend on users remembering to manually update the description after every posting. Two-Part Approach Existing Entries: One-time controlled update. New Entries: Automatic description population during the posting process. Updating Historical G/L Entries Since the system may already contain historical G/L Entries, simply implementing the logic for future postings would leave existing records without the enhanced description. To address this, we introduced a one-time action that allows the required description to be generated and stored for historical entries. The process can be represented as: Existing G/L Entries → Run Update Action → Determine Required Information → Generate Description → Update G/L Entry This approach provides a practical way to bring historical records into the same structure used for newly posted transactions. Maintaining the Description for New Entries Updating historical records solves only one part of the requirement. The same description logic also needs to be applied to future G/L Entries. Therefore, the solution ensures that the description is generated and stored when the relevant G/L Entry is created. This avoids a situation where historical records have the … Continue reading Enhancing General Ledger Visibility with Purchase Invoice Details in Dynamics 365 Business Central for a Maldives Financial Institution and an Abu Dhabi-Based Diversified Holding Company →