The Moss integration with Microsoft Dynamics 365 Business Central (MSBC) allows seamless synchronization of accounting and payment data between Moss and MSBC.
The integration uses standard Microsoft APIs combined with a lightweight Moss extension that deploys a few custom endpoints during connection. The overall design ensures data consistency, traceability, and minimal impact on the customer’s BC environment.
1. Data Imports (read operations)
Moss imports key master data from Business Central using standard BC API endpoints. These imports are used to validate and classify transactions before creating accounting records.
Data Object | API Endpoint | Purpose |
Chart of Accounts | /accounts | Imports the customer’s full chart of accounts, including account IDs, numbers, and names. Used to map Moss transactions to correct GL accounts. |
Vendors | /vendors | Imports vendor master data, including vendor IDs, names, and numbers, to link Moss payments and invoices to BC vendors. |
VAT Posting Setup | /vatPostingSetup | Retrieves VAT business and product posting groups, VAT %, and VAT code names from BC’s VAT setup tables to apply correct tax rates in Moss. |
Dimensions | /dimensions, /dimensionValues | Imports available dimensions configured in BC. Moss uses these to apply analytic tags (e.g. cost centers, departments) during transaction export. |
⚠️Note: Moss currently does not import or sync BC projects. Only standard dimension tables are supported.
2. Data Exports (write operations)
When transactions are ready for accounting, Moss exports them to BC as draft purchase invoices, purchase credit memos, and payment journal lines. These operations rely primarily on standard BC APIs, while the Moss extension provides a few supporting API pages for enhanced performance and validation.
2.1 Purchase Invoice Creation
Endpoint: /purchaseInvoices
Moss creates purchase invoices in draft status using vendor, tax, and dimension data previously imported from BC.
Functionality:
Creates a Purchase Invoice header and line items.
Applies vendor, VAT posting groups, and currency code.
Adds detailed line descriptions and dimension set associations.
Calculates total amount including/excluding VAT.
Example Request:
{
"vendorInvoiceNumber": "79154644",
"vendorNumber": "K00870",
"invoiceDate": "2025-09-25",
"postingDate": "2025-09-25",
"dueDate": "2025-09-25",
"currencyCode": "EUR",
"pricesIncludeTax": true,
"vatBusPostingGroup": "INLAND",
"purchaseInvoiceLines": [...],
"dimensionSetLines": [...]
}Response: Returns the created Purchase Invoice object with system-generated invoice number, totals, and vendor linkage.
2.2 Purchase Credit Memo Creation
Endpoint: /purchaseCreditMemos
Used for credit transactions or refunds related to Moss purchases. The payload and response structure mirrors that of purchase invoices, with negative line amounts or adjusted quantities.
2.3 Payment Journal Line Creation
Endpoint: /journalLines
After invoices are created, Moss generates Vendor Payment Journal entries to record payments and reconcile transactions.
Functionality:
Posts to a predefined journal batch (e.g.,
MOSS2).Links payment to the corresponding purchase document (
mossPurchaseDocumentNumber).Applies balancing GL account (e.g., clearing or bank account).
Maintains vendor linkage and currency consistency.
Example Request:
{
"journalId": "7a2e7735-1823-ed11-90eb-0022485c23c1",
"vendorId": "4b327804-5bba-f011-bbd1-00224813b514",
"accountType": "Vendor",
"postingDate": "2025-09-25",
"amount": 101.34,
"currencyCode": "EUR",
"balanceAccountType": "G/L Account",
"balancingAccountNumber": "1201",
"mossPurchaseDocumentNumber": "107599"
}
2.4 Attachment Handling
Endpoint: /attachments
Moss uploads receipts and supporting files directly to the created purchase documents.
Functionality:
Creates an attachment record linked to the parent purchase invoice or credit memo.
Uploads PDF receipts and audit logs.
Uses BC’s native file handling for secure storage and retrieval.
Example Request:
{
"parentId": "dbcf662c-d4ba-f011-bbd1-7ced8da973c2",
"parentType": "Purchase Invoice",
"fileName": "receipt--79154644.pdf"
}
3. Summary of API Endpoints Used
Action | BC Endpoint | Direction | Purpose |
Import Chart of Accounts | /accounts | Read | Load GL accounts for transaction mapping. |
Import Vendors | /vendors | Read | Retrieve vendor IDs and names. |
Import VAT Setup | /vatPostingSetup | Read | Fetch VAT groups and rates. |
Import Dimensions | /dimensions, /dimensionValues | Read | Import active dimensions for tagging. |
Create Purchase Invoice | /purchaseInvoices | Write | Record expense transactions. |
Create Purchase Credit Memo | /purchaseCreditMemos | Write | Record refund or credit transactions. |
Create Payment Journal Line | /journalLines | Write | Record payment reconciliations. |
Upload Attachments | /attachments | Write | Attach receipts and audit files to invoices. |
4. Functional Flow Summary
Data Sync (Import): Moss fetches master data (accounts, vendors, VAT setup, dimensions) from BC.
Transaction Preparation: Moss enriches transactions with correct BC references and dimension tags.
Export (Create Documents): Moss creates purchase invoices and credit memos in BC.
Payment Reconciliation: Moss posts payment journal lines referencing the same document.
Attachments: Moss uploads supporting receipts and audit logs to BC.
5. Security & Permissions
All data exchanges occur via the official Business Central REST/OData API under OAuth authorization.
Moss requires an admin consent in Microsoft Entra ID for API access.
No direct database access or code changes occur inside BC.
The integration is fully reversible — uninstalling the Moss extension or revoking API consent removes access immediately.
6. Extension-Specific Endpoints (for clarity)
While most operations use standard BC APIs, Moss’s custom extension endpoints are limited to a few technical helpers for efficiency:
Create / find purchase invoices and credit memos.
Get vendor bank accounts.
Get VAT posting setup.
Create / find journal lines.
Get payment journals.
All other functionality, including reading master data and attaching files, uses Microsoft’s standard API structure.
Technical details for installing & connecting the Moss extension to Microsoft Dynamics 365 Business Central
Below is a detailed summary of how the Moss extension for Microsoft Dynamics 365 Business Central (BC) is installed, what it does, and what your IT team should consider.
What is installed
Extension name: Moss Integration (Publisher: Moss)
Version: 1.2.0.0 • Target: Cloud • Runtime: 9.0 • Platform: 26.x.
appThe app deploys a small set of API pages (for journal lines, vendor payment journals, dimensions, attachments) and a light table extension on BC’s General Journal Line to add one Moss-specific reference field.
(Objects are prefixed “Moss…”, e.g., MossJournalLines, MossVendorPaymentJournals, MossDimensionValues, MossAttachment.)
How installation & connection works
Admin consent / approval: When you connect Moss to BC, your Microsoft Entra administrator (formerly Azure AD) grants consent for the Moss application to call BC APIs in your tenant. Admin consent is a standard step for BC API integrations.
Extension deployment: The Moss extension is installed to your BC tenant as part of that connection workflow (per-tenant install). Installing an extension in BC involves publish → sync → install, which is handled programmatically by the connection flow.
Note:
The Moss extension is not listed on AppSource; it’s delivered during connection. This is still a standard per-tenant extension deployment pattern supported by BC.
Moss uses the same connection to deliver upgrades and fixes in the background.
When the Moss API get’s disconnected, Moss automatically uninstalls the linked extension.
Data accessed or synced
Through the Moss extension, only a limited number of Business Central endpoints are used. These cover the core actions needed for journal posting, payables, and attachments. All other data exchange relies on Microsoft’s standard Business Central APIs without modification.
Area | Direction | Purpose / Notes |
Chart of Accounts | Read | Needed to validate GL accounts when creating journal lines (via BC’s standard journalLines API model). |
Vendors | Read | Used to reference vendor IDs/numbers when preparing payables-related journals. |
Tax/VAT codes | Read | Retrieved from BC’s VAT Posting Setup to ensure correct coding on journals. |
Dimensions & Dimension Values | Read | Dimension Values are exposed as read-only for validation; Dimension Set Lines are handled via a buffer page to associate them with journals (BC best practice for performance). |
General Journal Lines | Write | Moss writes journal lines (amounts, accounts, dimensions, etc.) via a dedicated API page aligned with BC’s journalLines model. |
Vendor Payment Journals | Write | Moss creates/updates Vendor Payment Journal batches and lines to stage payments. |
Attachments (receipts/invoices) | Read/Write | Receipts and invoice files are stored and linked using BC’s standard attachment buffer entities. |
Specifically, Moss only uses the following endpoints through its extension:
Creating and finding purchase invoices
Getting vendor bank accounts
Getting VAT posting setup
Creating and finding journal lines
Creating and finding purchase credit memos
Getting payment journals
This ensures the integration remains lightweight, transparent, and fully aligned with Microsoft’s supported API framework.
What changes are made to your BC environment
No core code modifications. This is a standard extension; it does not modify Microsoft base code.
New API pages for Moss entities (journal lines, dimensions, attachments, vendor payment journals).
One table extension that adds a Moss reference field on Gen. Journal Line (used to correlate entries with Moss).
Codeunits that handle attachments and update purchase header totals (ensuring amounts/VAT are consistent before posting).
Uninstallable: The app can be uninstalled like any other BC extension if needed.
Security & approval considerations for IT
Admin consent scope: Your Entra admin grants tenant-wide consent for Moss to access BC APIs for authorized companies in your tenant. This is the same OAuth model used by other BC integrations.
Principle of least privilege in BC: Within BC, make sure the Moss application (or the (service) user behind it) has the permission sets required for the described operations (journals, vendors, dimensions, attachments). Moss recommends assigning Super rights and special permissions for Extension Management to that user to avoid synchronisation issues
Data residency: All data exchanged stays within your BC tenant; Moss reads master data (CoA, vendors, dimensions) and writes journals/attachments only as required for the sync.
Attachments: Files are stored using BC’s standard attachment handling; content is moved via BC’s Attachment Entity Buffer types and linked to the appropriate records.
Change management: Because the app adds API pages and a small table extension only, risk to core processes is low. Still, we recommend validating in a Sandbox first, then promoting to Production—this follows Microsoft’s recommended process for extensions.
Monitoring & rollback: As with any BC app, you can view the extension in Extension Management and uninstall or revert if needed. Microsoft Learn
Moss does NOT recommend doing this as it breaks the functionality of the connection. Moss will automatically uninstall the extension if the application get’s disconnected.
Operational flow at a glance
Entra admin approves Moss → BC OAuth connection.
Moss installs & enables the per-tenant extension in your BC environment.
Moss reads your master data (CoA, vendors, dimensions, tax codes).
Moss creates/updates General Journal Lines and (optionally) Vendor Payment Journal lines to stage accounting/payment entries.
Moss stores links/files as attachments against the relevant entries using BC’s attachment buffers.
Transparency about the Moss app package
The app manifest shows resource exposure is enabled for debugging and source symbols, standard for supportability. (Fields: allowDebugging, allowDownloadingSource, includeSourceInSymbolFile.)
If helpful, we can coordinate a short call between your IT admin and our team to walk through the consent screen and a sandbox validation checklist.