Most Dynamics 365 implementations in Saudi Arabia do not fail because the platform cannot meet local requirements. They fail because businesses customise around problems that the platform already solves, or leave Saudi-specific compliance requirements until it is too late to scope them properly.
The result is predictable: project delays, rework, escalating costs, and in some cases, live systems that are not ZATCA-compliant at go-live.
The question for any Saudi business evaluating Dynamics 365 is not "how much can we customise?" It is "what genuinely needs to be customised, and what should we leave standard?"
The risks of getting this wrong include:
- Go-live delays caused by late-stage compliance rework
- Custom code that breaks or requires expensive rebuilding after Microsoft updates
- ZATCA e-invoicing failures due to untested or incorrectly configured workflows
- Higher long-term support and maintenance costs from unnecessary complexity
- Licence and audit exposure from configurations that do not meet Saudi regulatory requirements
The Most Common Dynamics 365 Customisation Mistakes Saudi Businesses Make
Industry experience across Saudi Dynamics 365 projects points to four mistakes that appear consistently, regardless of business size or sector.
1. Customising what Dynamics 365 already handles natively
Dynamics 365 includes structured, built-in localisation for Saudi Arabia. This covers ZATCA Phase 2 e-invoicing integration, VAT at 15%, Arabic UI, Hijri calendar support, and bilingual document output. Businesses that treat these as gaps to be filled with custom development are adding cost and complexity to a problem that is already solved. The Microsoft Dynamics 365 Finance localisation documentation is explicit: Saudi e-invoicing requires specific feature configuration and onboarding, not custom-built workarounds.
2. Scoping ZATCA, VAT, and Arabic requirements as late-stage tasks
Compliance configuration in Saudi Arabia is not a finishing step. It is a core workstream. Businesses that treat ZATCA e-invoicing setup, VAT code mapping, and Arabic document design as post-go-live activities routinely face costly rework. These requirements affect the chart of accounts, invoice output formats, and API integration with the FATOORA platform, all of which need to be designed from the start.
3. Using custom development to fix process problems
One of the most expensive patterns in Saudi ERP projects is building custom code to replicate broken or poorly designed internal processes inside the new system. The result is a Dynamics 365 environment that inherits the organisation's existing problems in a more expensive form. As one widely cited industry benchmark puts it, successful ERP implementation is 30% technology and 70% preparation, people, and process alignment.
4. Selecting a partner based on customisation promises rather than implementation judgement
A partner who leads with "we can build anything you need" is not the same as a partner who can tell you what you should and should not build. In a Saudi implementation, that distinction matters. Partners without genuine local compliance experience often default to custom development when standard configuration, correctly set up, would have been faster and cheaper.
What to Customise and What to Keep Standard in a Saudi Implementation
The practical question every Saudi business needs to answer before an implementation starts is not "can we customise this?" but "does this genuinely need to be customised?"
A localisation-first approach means exhausting what Dynamics 365 already supports for Saudi Arabia before approving any custom build. Microsoft's Commerce localisation for Saudi Arabia already covers VAT configuration, fiscal registration, QR code printing, CSID-based digital signing, and e-invoice submission workflows natively.
The table below gives a working framework for implementation scoping decisions:
Keep Standard
Consider Customising
ZATCA Phase 2 e-invoicing integration via FATOORA API
Industry-specific approval workflows not covered by standard D365 logic
VAT at 15%, tax codes, and tax group configuration
Customer-facing document formats with brand or contractual requirements
Arabic UI and right-to-left interface configuration
Reporting outputs required for internal Saudi business units or government submissions beyond standard tax reports
Hijri calendar support and bilingual document output
Integrations with third-party Saudi systems not covered by standard connectors
Chart of accounts structured for Saudi VAT reporting
Sector-specific operational workflows where standard D365 process design does not match business reality
QR code generation and digital certificate (CSID) setup
Localised HR or payroll rules where standard configuration cannot meet GOSI or Saudisation requirements
Key rule: If a requirement is already covered by Microsoft's Saudi localisation feature set, customising it is unnecessary overhead. If a requirement is genuinely outside standard capability and operationally critical, customisation is justified. The test is whether the customisation will still be needed after the next Microsoft release wave.
A phased deployment approach, typically finance and compliance first, followed by operations, helps businesses validate standard localisation before committing to custom builds in later phases.
Saudi-Specific Requirements That Must Be Scoped from Day One
The following requirements are non-negotiable for any Dynamics 365 implementation in Saudi Arabia. Treating any of them as a later-phase task creates compliance exposure and rework.
ZATCA E-Invoicing (FATOORA Integration)
- Onboard with ZATCA to obtain Compliance (CCSID) and Production (PCSID) Cryptographic Stamp Identifiers before go-live
- Import the Saudi Arabian Zatca submission (SA) feature version 14 or later from Globalization Studio
- Configure the FATOORA API endpoint, number sequences, and QR code response mapping in Finance
- Test in ZATCA's compliance environment before deploying to production
- Deadline note: Businesses with VAT revenues above SAR 375,000 must complete Phase 2 integration no later than 30 June 2026
VAT and Financial Configuration
- Set up Saudi-compliant tax codes, tax groups, and item tax groups from project initiation
- Structure the chart of accounts to support VAT reporting from day one
- Enable bilingual (Arabic and English) invoice output across all relevant legal entities
Arabic Localisation and Document Design
- Configure right-to-left interface across all relevant modules
- Design bilingual customer-facing documents, including invoices, delivery notes, and purchase orders, as part of the core build, not as post-go-live additions
How to Evaluate a Dynamics 365 Partner Before Customisation Starts
Choosing the right implementation partner is the single decision that most determines whether a Saudi Dynamics 365 project stays on budget and on time. The right questions to ask before signing an engagement:
- How do you decide between standard configuration, Microsoft's Saudi localisation features, and custom development? A strong partner will have a clear methodology. Vague answers here are a warning sign.
- Have you completed ZATCA Phase 2 integration for a Saudi business before? This is not a theoretical question. CSID onboarding, FATOORA API configuration, and compliance environment testing require hands-on experience.
- What is your recommended deployment sequence for a Saudi implementation? Finance and compliance first is the standard approach for good reason. Partners who propose a broad simultaneous rollout without a phased rationale carry higher delivery risk.
- Can you show us examples of Saudi-specific document design and Arabic workflow configuration from previous projects? Localisation capability should be demonstrable, not just claimed.
- How do you handle Microsoft release waves and post-go-live updates for customised components? Custom code requires active maintenance. Understanding the partner's upgrade approach protects the business from accumulating technical debt after go-live.
Partners with genuine Saudi implementation experience will answer these questions with specifics. Those without it will not.
Getting the Customisation Decision Right
A successful Dynamics 365 implementation in Saudi Arabia is not defined by how much the system has been customised. It is defined by how well the implementation team understood what the business genuinely needed, what Microsoft already provided, and where the line between the two sat.
Businesses that start with localisation-first thinking, scope compliance requirements early, and challenge every custom development request against standard capability will arrive at go-live faster, with lower ongoing costs and a more maintainable system.
Ready to scope your Dynamics 365 implementation correctly? Terracez offers a structured customisation assessment for Saudi businesses, covering ZATCA compliance readiness, localisation requirements, and a clear view of what to build versus what to configure. Request a discovery call to get started.
.webp)
