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 Emirates-based marine services firm running Microsoft Dynamics 365 Business Central found that an approved purchase order had disappeared, along with every record of who approved it. We confirmed the order had been deleted rather than archived, showed why Business Central removes approval entries together with the document, and identified the likely approvers from the approval chain. We then explained how a point-in-time restore of Production into a sandbox recovers the actual approval history, set up the change log so future deletions are recorded in full, and recommended controls that stop approved documents from being deleted at all. Table of Contents Introduction Understanding the Issue Deleted or Archived? How We Confirmed It Why the Approval Entries Disappeared Reconstructing the Likely Approvers Recovering the Evidence with a Point-in-Time Restore Making Future Deletions Traceable Preventing Approved Documents from Being Deleted Business Impact Frequently Asked Questions Conclusion Introduction Approval workflows in Microsoft Dynamics 365 Business Central give finance teams confidence that every purchase order was reviewed before it went to a vendor. That confidence depends on one assumption: the approval history will still be there when someone needs it. For an Emirates-based marine services firm we work with, that assumption broke. The finance team went looking for a released purchase order and could not find it. When they checked Approval Entries, there was nothing there either. A few days later, two purchase invoices were deleted as well, and the change log had no record of them. 1 Approved purchase order missing 0 Approval entries left for it 28 Days available to recover the evidence This post walks through how we investigated the issue, what Business Central does behind the scenes when a document is deleted, and the setup that makes every future deletion traceable. The Lesson In Business Central, deleting a document also deletes its approval history. Audit trails have to be set up before they are needed, not after. Understanding the Issue The finance team came to us with three questions. Each needed a clear, evidence-based answer. 01 Was It Deleted or Archived? The order was in Purchase Order Archives, so it looked as if someone had simply archived it by hand. 02 Who Approved It? The order had been released through an approval workflow, but Approval Entries showed nothing for it. 03 Why Was Nothing Logged? The change log had just been switched on, yet the invoices deleted afterwards left no trace in it. Deleted or Archived? How We Confirmed It Archiving and deleting both leave a copy in Purchase Order Archives, so the archive alone does not tell you what happened. The difference is what remains in the live system. Archived Archive Document A copy is saved to Purchase Order Archives, but the original order stays in the Purchase Orders list, together with its approval entries. Deleted Delete The order leaves the Purchase Orders list. If Purchases & Payables Setup is set to archive orders, Business Central saves an archive copy automatically at the moment of deletion. We worked through the possibilities one at a time: How we ruled out each possibility Not in Purchase Orders → No Receipts, Invoices or G/L Entries → Only in Archives → Version No. 1 → Deleted The Version section of the archived order settled it: Version No. 1: only one archived version existed, so the order had never been archived by hand. This version was created when the order was deleted. Archived By: the user ID that deleted the order. Date and Time Archived: the exact moment of deletion. Figure 1: The archive version details show who deleted the order and when. Why the Approval Entries Disappeared Approval entries are linked to the document they belong to. When the document is deleted, Business Central deletes its approval entries too. The archive keeps the order’s header and lines, but not its approval history. To show this to the client with evidence rather than theory, we reproduced it on a copy of Production using an older released order: 1 Released Order We picked a purchase order that had been released through the approval workflow. 2 Approvals Recorded Its Approval Entries showed three approvals from three different approvers. 3 Order Deleted After the order was deleted, Approval Entries showed nothing for it. 4 Archive Copy Remains The order was still available in Purchase Order Archives, without its approvals. Figure 2: Before deletion, the test order carries its full approval history. Figure 3: After deletion, the approval entries are gone, even though an archive copy exists. Key Insight Purchase Order Archives answer what the order looked like. They do not answer who approved it. Once a document is deleted, that question can only be answered from a backup. Reconstructing the Likely Approvers With the approval entries gone, we looked at the next purchase order raised by the same user. Approvals follow the approver chain set up in Approval User Setup, so an order from the same requester with a similar amount follows the same route. Step Role What Happens 1 Requester Raises the purchase order and sends it for approval 2 First approver Next user in the requester’s approver chain 3 Second approver Next user in the chain, based on the approval limits A Reconstruction, Not a Record This identifies the most likely approvers, but it is not proof. It assumes the approval setup has not changed since, and that the deleted order’s amount did not cross a limit that would have added another approver. Recovering the Evidence with a Point-in-Time Restore Business Central Online lets you restore an environment to any point in time within the last 28 days. A Production environment can be restored as a new sandbox, which leaves Production untouched. In that copy, the deleted order still exists with all its approval entries. Steps We Recommended In the Business Central Admin Center, open the Production environment and choose Restore. Pick a point in time a few minutes before the deletion. Convert the archive’s timestamp to the time zone the Admin Center … Continue reading Recovering Lost Approval History After a Purchase Order Deletion in Business Central →

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 →

01Summary Project-based businesses often run their projects in Dynamics 365 Project Operations and their finance in Dynamics 365 Business Central. The two systems do not talk to each other out of the box, so every customer, project, timesheet, expense and invoice ends up being typed into both, and the numbers finance reports on are always a step behind the project teams. CloudFronts built an integration that closes this gap using Dataverse plugins: small pieces of C# code that run inside Project Operations every time a record is saved. When someone creates a customer, sets up a project, approves a timesheet or confirms an invoice, the plugin sends that record straight to the matching Business Central web service and writes the Business Central number back onto it. Before material is used on a project, it looks up how much stock Business Central holds at that location. Anything that fails is saved in an Error Log with the exact data that was sent. To keep the examples concrete, this post follows a sample scenario: Wexford County Council orders a satellite broadband installation at its Castlemoyle and Bunclody water treatment sites, and the project runs from the first lead to the final invoice across both systems. Table of Contents 01Summary→ 02Business Challenges→ 03Solution Overview→ 04Technical Approach→ 05Business Impact→ 06Conclusion→ 02Business Challenges Project Operations and Business Central each work well on their own. The trouble is the gap between them: nothing entered in Project Operations reaches Business Central unless someone types it in again. Without an integration, teams run into the same problems: Everything is entered twice. A new customer or project is created in Project Operations, then created again in Business Central. Every later change has to be repeated by hand. Master data drifts apart. Countries, postcodes, currencies, payment terms, dimensions and work types have to match in both systems. When one side changes and the other does not, records fail to post. Approved work reaches finance late. Approved timesheets, expenses and material only arrive in Business Central after someone exports and imports them, so project costs in finance are always behind. Material is used without checking stock. Site teams log material against a project without knowing whether Business Central actually has it at that location. Invoices are keyed twice. A confirmed project invoice has to be rebuilt in Business Central, line by line, before finance can post it. Errors are hard to trace. When a record does not match, nobody can see what was sent or why Business Central rejected it. 03Solution Overview CloudFronts built one main plugin, RequestProcessor, and registered it on every Project Operations table that finance needs. Two small helper plugins handle the stock check for material. Whenever one of those records is created, updated or deleted, Dataverse runs the plugin. The plugin works out which table the record came from, turns it into the shape Business Central expects, and sends it to the matching Business Central web service. When Business Central replies, the plugin stores the Business Central number on the Project Operations record, such as the BC customer number or the project code. Next time the record changes, the plugin uses that number to update the same record in Business Central instead of creating a new one. All the settings the plugin needs, such as where to sign in, which web service to call for each table, and which user is the integration user, live in a single Integration Configuration record in Dataverse. Moving from a test company to the live one is a change to that record, not to the code. ⓘKey terms, in plain words Dataverse plugin: C# code that Dataverse runs automatically when a record is saved, like a trigger in a database. Business Central web service: an address in Business Central that accepts records from other systems, one for customers, one for projects, and so on. Project Journal: where costs are recorded against a project in Business Central before they are posted. Project Planning Lines: the budget of a project in Business Central. ⓘWhy a plugin instead of Power Automate? A cloud flow could copy simple records, but this integration covers 20 tables with detailed mapping rules for each one. In a plugin, that logic lives in one C# project that can be versioned, reviewed and tested like any other code. The plugin runs the moment the record is saved, only on the tables and messages it is registered for, and it ships in the same Dataverse solution as the rest of the Project Operations customisation. 04Technical Approach How It Works Every save takes the same path through the plugin: A record is saved in Project OperationsFor example, the project manager approves a week of time entries on the Wexford County Council broadband project. RequestProcessor loads its settingsIt reads the Integration Configuration record. If the record is missing, the plugin stops quietly instead of failing the user’s save. It skips its own changesIf the record was last modified by the integration user, the plugin stops. This keeps it from running again on the Business Central number it has just written back. The handler for that table maps the recordIt checks the record’s status, so only approved entries or confirmed invoices go further, and copies the fields into the JSON shape Business Central expects. Business Central creates or updates the recordPOST creates a new record; PUT updates the one already linked by its Business Central number. The result is savedOn success, the Business Central number is written back onto the Project Operations record. On failure, an Error Log record is created with the details. What Moves Between the Systems The plugin handles 20 Project Operations tables. They fall into five groups, in the order a project normally runs. Group Saved in Project Operations Created in Business Central When It Is Sent Customers Account Customer, or Vendor when the account type is Vendor Create and update; a delete blocks the record in BC instead of removing it Customers Contact Contact Create, update and delete … Continue reading How We Built a Project Operations to Business Central Integration Using Dataverse Plugins →

Summary Most project businesses we work with have the same quiet problem. The project team plans and tracks work in Dynamics 365 Project Operations. The finance team bills, buys and closes the books in Dynamics 365 Business Central. Everything the project team decides has to be typed again by finance. The two teams spend their week checking each other’s numbers. At CloudFronts we closed that gap with plugins: small automatic helpers that sit inside Project Operations and act the moment someone saves a record. When a project, a plan, a timesheet or an invoice is saved, the helper creates the matching record in Business Central and writes the Business Central reference back on the project. This integration is available as the PO-BC Integration Module 2.0 on Microsoft Marketplace. To show how this works in practice, we ran a real example through our demo environment: CloudFronts – Smart Office Rollout, Mumbai, a short project to fit out a new office floor. Every screenshot in this post comes from that one project. Table of Contents Summary→ Business Challenges→ The Idea in Plain Words→ Walkthrough: The Mumbai Office Rollout→ What Moves, and When→ The Safety Nets→ What We Learned Building It→ Business Impact / Key Takeaways→ Questions We Get Asked→ Conclusion / Final Thoughts→ Call to Action / Connect With Us→ Business Challenges Picture the Mumbai office rollout without any connection between the two systems. Monday. The project manager sets up the project, splits it into four tasks and plans 104 hours of work in Project Operations. Finance is told about it in an email. Tuesday. Finance creates the same project in Business Central, retypes the four tasks, and builds a budget from a spreadsheet the project manager sent over. One task name is spelt differently. Nobody notices. Wednesday. The plan changes: cabling needs an extra day. Project Operations is updated. The budget in Business Central is not. Thursday. Twenty desks are taken from the warehouse for the new floor. The site team records it in Project Operations. Business Central still believes the desks are on the shelf. Friday. Finance asks why the project margin looks wrong. Two people spend the afternoon comparing screens. None of this is anyone’s fault. Each system is doing its job. They just do not talk to each other. The Idea in Plain Words A plugin is a small piece of code that lives inside Project Operations and wakes up at a specific moment, for example when a project is saved or a timesheet is approved. Ours does three things each time it wakes up: It reads what just changedThe project name, the customer, the task, the hours, the item and quantity: whatever finance would otherwise have to retype. It creates or updates the same record in Business CentralIt signs in to Business Central with its own dedicated account, not a person’s login, so it keeps working when people change roles or leave. It writes the answer backBusiness Central replies with its own reference, such as a project number or an invoice number. That reference is saved on the Project Operations record, so both teams can always find the matching record in the other system. 💡Why a plugin and not a scheduled sync? A scheduled sync runs every hour or every night and moves whatever has changed. A plugin acts on the exact save, so Business Central is updated within seconds, and only the record that changed is sent. It is also packaged with the rest of the Project Operations setup, so moving it from the test system to the live one is a single, repeatable step. Walkthrough: The Mumbai Office Rollout Here is the same week again, this time with the integration switched on. The customer is CloudFronts Technologies, already known to Business Central as customer C00310. The work is 40 new workstations, meeting-room screens and office Wi-Fi. The customer account, integrated to Business Central with its customer number sent back. Step 1: The Project Manager Creates the Project, Once The project manager creates the project in Project Operations with a name, the customer, a start date of 12 October and a finish date in December. The project code is left blank because nobody knows it yet. A few seconds after saving, the code J00700 appears in the Project Code field. That number came back from Business Central. The project integrated to Business Central. The project code J00700 was filled in automatically. Step 2: The Tasks Follow The project manager adds four tasks in the project plan: Site Survey and Floor Plan, Network Cabling and Wi-Fi, Workstation and Screen Installation, and Testing and Handover. Each one is created under project J00700 in Business Central with the same name and dates, numbered 1272 to 1275. Finance did not open anything. Step 3: The Plan Becomes the Budget Next, the project manager assigns a named person to each task: 16 hours for the survey, 40 for cabling, 32 for installation and 16 for testing and handover. The integration turns that plan into budget lines in Business Central, one line per working day per person, so finance sees not only how much work is planned but when it falls. Weekends are skipped automatically. Resource assignments from Project Operations, turned into daily planning lines in Business Central. ⓘWhy one line per day? A single line of "104 hours" tells finance the total but nothing about timing. Daily lines let finance see cost landing in October versus November, which matters at month end. If the plan changes, the same lines are updated, not duplicated. Step 4: Real Work and Real Material Arrive as Actuals On 12 October, the consultant logs a day on the site survey: "Walk-through of the new floor; desk layout and cable routes agreed with facilities." A week later, the site team records 20 ATHENS desks taken from the Main Warehouse for the installation task. The integration does not send rough drafts. Time and material only go to Business Central once they are submitted for approval, and the … Continue reading No More Retyping: How We Connected Project Operations and Business Central with Plugins →

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 →