Dynamics keeps raising the invoice exactly as it does now. The connector takes over after that: the invoice data leaves Dynamics 365 Business Central through its E-Document framework, is validated against the destination country’s own rules, is delivered to the buyer over Peppol, and comes back as a status your finance team can see.
The recording runs 10 minutes 23 seconds in thirteen chapters: why Dynamics is not one product, how the Business Central E-Document framework works, an invoice sent from Dynamics to GoRoute, validation and Peppol delivery with tracking, Oman Fawtara readiness, credit notes and retries, and why webhook-only integrations can fail. The same walkthrough is written out further down the page, chapter by chapter, if you would rather read it than watch it.
Below is the recording written out, chapter by chapter and in its own order, so the page answers what the Dynamics connector does without anyone pressing play. Nothing here describes a screen the recording does not show; where a rule identifier or a field constraint comes from the Oman Dynamics guide or the Microsoft integration page rather than from the video, it says so.
Because the invoice your finance team produces and the document a tax regime accepts are not the same object. Dynamics produces a correct accounting document; a mandate asks for a structured file in a named profile, carrying fields that never appear on a printed invoice, validated against a published rule set and delivered over a specific network. The gap between those two is what a connector exists to close, and the recording opens by naming it rather than by showing a screen.
Dynamics is not one product, and that is the first thing the walkthrough says. Business Central, Finance & Operations, Sales and Customer Service, and older on-premise systems each take a different integration path. Treating a Dynamics estate as one thing is how integration projects arrive at the wrong estimate and discover it in month three.
The product view of the wider Microsoft relationship — Azure deployment, Power Platform connectors, Business Central extensions, Office 365 notification paths — is on the Microsoft integration page. This recording deliberately narrows to one product and follows a single invoice through it, which is more useful than a diagram covering everything.
Because Business Central already has a place for this. Microsoft ships an E-Document framework in the product, so the connection is an extension of something the ERP is built to do rather than a bolt-on that has to be defended at every upgrade. That matters commercially as much as technically: an integration living inside the vendor’s own framework survives the next release, and one built around it has to be re-tested every time.
It gives a posted sales document a second life as an electronic document, with a service defining where that document goes and what happens to it. The finance user posts an invoice the way they always have; the framework hands the document to the configured service; the service is what carries it out of Business Central. The practical consequence is the one finance teams care about: nobody learns a second screen, and no parallel process runs alongside the ledger.
The invoice data leaves Dynamics as structured data and is converted into UBL 2.1 XML in the profile the destination requires — the Peppol PINT Oman profile for an Omani buyer, the applicable national profile elsewhere. From that point the document is the platform’s responsibility rather than the ERP’s, which is the whole architectural argument: your ERP should not be the place where twelve countries’ invoice rules live.
Volume is handled at this boundary too. Batch submission takes between 1 and 1,000 invoices in a single request, with validate and process as separate stages. That shape matters at month-end, when the invoices arrive in an hour rather than across a day, and it is where an integration that sends one invoice per call tends to fail.
Validation runs before anything is sent, against the full rule set for the
destination — for Oman that is PINT OM 1.0.1 including its Schematron rules.
What comes back is a compliance report naming the rule that fired by its own
identifier, not a bare pass or fail, because IBR-069-OM
is a ticket somebody can act on and “invalid tax line” is a conversation.
Three layers can refuse an Oman document, and the sizes are worth knowing before anyone estimates the work. Counted in the packs GoRoute ships on 22 August 2026: the shared Peppol PINT layer holds 170 rules, every one fatal; Oman’s own jurisdiction pack holds 155, of which exactly two are warnings; and the tax data document has its own pack of 66 rules, all fatal.
Delivery is over Peppol, from our certified Access Point to the buyer’s, and the transaction stays findable afterwards with its status attached. Severity comes from the rule file rather than from how a message reads: three Oman rules are worded should and are flagged fatal, so advice-sounding text can still refuse a document.
Mostly master data, and almost none of it is technical work. Four values decide whether Oman’s rule packs accept the document, and each one lives in an ordinary Dynamics record:
IBR-003-OM requires the seller, buyer and any third-party VAT identification number to be exactly twelve characters: OM followed by ten digits. That sits on your company record and across your customer records.IBR-002-OM requires a valid UUID version 5 on every invoice. Not any UUID — version 5.IBR-001-OM and IBR-043-OM require a twenty-character string of ones and zeros, with the first or second position always set to one. It has no equivalent field in a stock Dynamics install.IBR-079-OM and IBR-080-OM require a twelve-digit Harmonized System code on a goods line, and IBR-081-OM an industrial classification code on the item.
One more constraint catches ERP configurations that were never wrong before:
IBR-DEC-03-OM refuses any
amount carrying more than three decimal places, because the rial has 1,000 baisa. Two
decimals is the default almost everywhere else. The single most useful number to
establish in week one is how many active Dynamics customers have no usable VAT
identifier — that figure is the size of the data work, and it is much better
known early than in week nine. The full field-by-field version is in
Oman e-invoicing from Microsoft Dynamics 365.
This is the chapter worth watching even if you watch nothing else, because it is where most integrations turn out to be incomplete. An invoice that sends is easy. A credit note that references the correct preceding document, a retry that does not create a duplicate, and a status a finance team can see without asking IT are the parts that decide whether the system is still usable in month three. A version 5 UUID is what makes a retry recognisable as a retry rather than as a second invoice, which is why Oman specifies that version rather than any UUID.
A webhook that is missed — an endpoint down for ten minutes, a deployment, a firewall change — is a document whose status nobody knows. If the design has no second way to ask, the system loses things quietly, and quietly is the dangerous part: nothing alerts, and the gap surfaces during an audit. Pushed events plus a status you can query is the pairing that survives. This is a genuine architectural warning rather than a product pitch, and it applies whichever provider you choose.
Three audiences want three different things from the same system. The ERP team wants an integration inside Microsoft’s own framework that does not have to be rebuilt at the next upgrade. Finance wants nothing to change about how an invoice is raised, and a status visible without raising a ticket. Compliance wants the audit trail: timestamps, signatures, delivery receipts and authority responses, retained for the statutory period, and for Oman held in-country — invoices, keys, tax data documents and audit logs.
Four things, and saying so is more useful than implying otherwise. It does not settle which Dynamics product and version your estate runs, nor how the connection is packaged for your tenant. It does not settle your own customisations and data quality. And it does not settle which of Oman’s two mandate dates applies to you: Decision 189/2026 makes electronic tax invoices mandatory from 1 April 2027 for taxable persons whose annual supplies exceed OMR 5,000,000, and from 1 October 2027 for those at or below that figure — by annual supplies, not by headcount, sector or which ERP you run.
What you can do without talking to anyone is validate a real Dynamics invoice against the real Oman rule set in the sandbox; validation-only calls carry no per-call charge. The regulatory view of the same path is in Oman e-invoicing from Microsoft Dynamics 365, the market as a whole is on the Oman page, and if it is easier to talk it through against your own estate, book a working session.
Dynamics is not one product. Business Central, Finance & Operations, Sales and Customer Service, and older on-premise systems each take a different integration path, which is why the walkthrough starts with Dynamics 365 Business Central and its E-Document framework. Which product and version apply to your estate is a question to ask and have answered in writing.
It does not go there directly. Dynamics raises the invoice as it always did; the data leaves Dynamics as structured data, is validated against Oman's rule packs, is rendered as UBL 2.1 XML in the Peppol PINT Oman profile, and travels to the buyer over the Peppol network. A separate tax data document, derived from that invoice, is what reaches the Authority.
Master data, not the integration. Oman's rule pack requires VAT identification numbers of exactly twelve characters, OM followed by ten digits, under IBR-003-OM; a version 5 UUID on every invoice under IBR-002-OM; a twenty-character transaction type of ones and zeros under IBR-001-OM; and a twelve-digit Harmonized System code on goods lines under IBR-079-OM and IBR-080-OM. All of it lives in ordinary Dynamics customer, company and item records.
By validating a real one. The document is checked against the full PINT OM 1.0.1 rule set including its Schematron rules, and the response names the rule that fired by its own identifier rather than returning a bare pass or fail. Validation-only calls carry no per-call charge, so correcting a mapping across forty attempts costs nothing.
Because a webhook that is missed is a document whose status nobody knows. A design with no second way to ask loses things quietly. The chapter at 06:05 makes the case for pairing pushed events with a status you can query, and it applies whichever provider you choose.
The same dates as everyone else, because they depend on annual supplies rather than on which system you run. Decision 189/2026 makes electronic tax invoices mandatory from 1 April 2027 for taxable persons whose annual supplies exceed OMR 5,000,000, and from 1 October 2027 for those at or below that figure.
This recording shows the same platform you would be buying, doing the thing you would be buying it for — on a Peppol-certified access point.
Press Esc, click outside, or use the ✕ to close and stop playback.