This article describes the known limitations of the iPaaS.com integration for Microsoft Dynamics 365 Business Central. These limitations are inherent to the current design of the integration and to the capabilities of the Microsoft Dynamics 365 Business Central platform, and they apply to all subscribers at the time this documentation was written. They are not defects — they describe how the integration behaves by design so that subscribers or their MiSP can plan their configuration accordingly. Limitations may change as the Microsoft Dynamics 365 Business Central platform evolves and as the integration is enhanced.

When a transfer is rejected or behaves unexpectedly, the details are available in the iPaaS.com Dashboard under Integration Monitoring and in the Error Logs.

This integration was built for Microsoft Dynamics 365 Business Central and communicates with the Business Central cloud business API (version 2.0). It was last validated against Business Central on 2026-06-25; the integration targets the documented production business API as of that date.

This integration is not built for other products in the broader Microsoft Dynamics family and should not be pointed at them. In particular, it does not support:

If Microsoft introduces a separate product line or a materially different Business Central API generation in the future, this integration will not automatically support it.

For data captured from Business Central into iPaaS.com — such as customers, contacts, companies, products, inventory, locations, shipping methods, sales orders, and posted sales invoices — the integration periodically checks Business Central for new and changed records on its polling schedule and brings them into iPaaS.com. Business Central does not push live webhook events to the integration for these flows, so there is no inbound webhook event to subscribe to.

What this means for you: Records captured from Business Central appear in iPaaS.com on the integration's polling cadence rather than the instant they change. The lookback window for posted sales invoices is governed by the Transaction Poll Search Days preset in the subscription configuration, which limits polling to recent records. There are no automatic captures until polling is configured for the subscription. Subscribers or their MiSP who need an immediate transfer can run a Manual Sync at any time.

Data written from iPaaS.com into Business Central — customers, companies, products, open sales orders, and posted invoices — dispatches automatically only once subscribers or their MiSP subscribe to the relevant create and update events in the subscription configuration's Outbound Data Flows section. Until those subscriptions are enabled, no automatic transfers occur in this direction.

What this means for you: Enable the appropriate Outbound Data Flow subscriptions during setup so records flow into Business Central automatically. Manual Sync is always available from the iPaaS.com Manual Sync page, including before any outbound triggers are enabled. Whether an incoming record is created or updated in Business Central is decided by whether it is already linked to a Business Central record, not by which event fired.

Customer, contact, company, sales order, and sales invoice addresses are captured as part of their parent record's transfer rather than on their own. They have no independent trigger, schedule, or Manual Sync of their own, and they cannot be created, updated, or deleted as standalone records.

What this means for you: To capture an address, transfer its parent record (for example, run a Manual Sync of the parent customer using the customer number); the address transfers with it. There is no way to sync an address by itself.

When the company-hierarchy option is enabled for the integration, a company's direct parent-company link is captured alongside the company. Sibling relationships and multi-level hierarchies beyond the direct parent are not processed. The parent link is captured only when the Business Central company has a parent customer assigned and when the parent company already exists, or can be created, as a company in iPaaS.com.

What this means for you: Enable the company-hierarchy option in the subscription configuration if you want parent-company links captured, and make sure parent companies exist as companies in iPaaS.com. Expect a single direct parent relationship per company — deeper hierarchy structures are not represented.

Note: Company relationships are limited to person relationships (the relationship type Person). Other relationship types are not captured through the company relationship collection.

Locations, product inventory, shipping methods, customer categories, and product categories are captured from Business Central into iPaaS.com but are read-only in that direction — they do not accept create, update, or delete operations from iPaaS.com into Business Central. The posted sales invoice family captured from Business Central is likewise capture-only.

What this means for you: Treat Business Central as the source of truth for these entities. Maintain locations, inventory, shipping methods, and categories in Business Central; the integration reflects them into iPaaS.com but will not write changes to them in the other direction.

When transactions are written from iPaaS.com into Business Central, an order in a Pending status is created or updated as an open sales order, while a completed order (status Complete) is posted as an invoice. These two flows are mutually exclusive by status, so the same transaction is never both written as an open order and posted as an invoice.

What this means for you: A transaction flows down exactly one path based on its status. Confirm the status filters on these collections match your workflow before enabling them together, and decide which system is the source of truth for order and invoice data so the same transaction is not written in conflicting directions.

Note: A posted invoice cannot be edited in Business Central. After an invoice is first posted, later updates to the same transaction add new customer payments to the existing posted invoice rather than re-posting the header or lines.

The integration creates and updates records but does not delete them. Capturing data into iPaaS.com does not remove iPaaS.com records, and writing data into Business Central does not delete Business Central records, including posted invoices and posted payments.

What this means for you: Removing a record in one system does not remove it in the other. Handle deletions and archival directly in each system according to your business process.

When a sales order is written into Business Central, any line item whose SKU matches the value configured in the order's excluded-SKU preset is skipped and is not written to Business Central.

What this means for you: Review the excluded-SKU preset during setup so that only the SKUs you intend to exclude are skipped. Line items you expect to write must not match the excluded value.

When sales orders are captured from Business Central into iPaaS.com, only orders in the Released status are captured. Orders in earlier statuses are not captured until they reach Released.

What this means for you: A Business Central sales order appears in iPaaS.com after it is released, not while it is still being drafted. If you expect an order in iPaaS.com and do not see it, confirm the order has been released in Business Central.

When a customer is updated in Business Central from iPaaS.com, the Customer Posting Group, Gen. Bus. Posting Group, Payment Terms Code, and Tax Area Code are written on every update from the values configured in these mappings. The companion company-update flow preserves these fields instead of writing them.

What this means for you: Because these values are written on each customer update, any value maintained directly on the Business Central customer for these four fields is replaced on the next update from iPaaS.com. The mappings ship with example values that will not match your company — replace each with a value configured in your Business Central setup before the first transfer, or the transfer fails when Business Central rejects an unknown value. If you need different values per customer, adjust the mappings or maintain those fields in Business Central through a different process.

Note: This applies to the customer-update flow from iPaaS.com into Business Central. Other fields that are left unmapped or empty are not overwritten — only values that are supplied are written, and empty values are never sent.

Business Central invoice statuses are normalized to standardized iPaaS.com statuses when an invoice is captured. At the header level, Shipped, Partially Shipped, Cancelled, and Released map to Shipped; Completed maps to Complete; and Pending, In Progress, and Submitted map to Pending. The line-level rule used by the line-item collections treats some statuses differently — for example, Completed and Cancelled are handled differently at the line level than at the header level. A Business Central status not covered by the mapping passes through without translation.

What this means for you: If invoice status fidelity matters in your downstream systems, review both the header status normalization and the line-level status behavior so you understand how each Business Central status is represented in iPaaS.com.

iPaaS.com supports assigning multiple categories to a customer, whereas Business Central allows only one customer price group. When a customer is written into Business Central, the price group is set from the first category in the list, and only when that category resolves to a price group configured in Business Central.

What this means for you: Only the first category drives the Business Central price group. If a specific price group should apply, make sure the corresponding category is first and that it maps to a configured Business Central price group.

When an order or invoice address is captured from Business Central into iPaaS.com, the contact's first and last name are derived from the address name by splitting it on spaces: the first word becomes the first name and the second word becomes the last name. A name with a single word leaves the last name empty, and a name with more than two words contributes only its first two words.

What this means for you: Names with a middle name, multiple words, or a suffix may not separate as you expect. If your downstream systems depend on precise first- and last-name values, review how your Business Central address names are formatted, or adjust the name mapping to match your naming conventions.

When customers and contacts are captured into iPaaS.com, the integration matches and links records by email address to avoid creating duplicates. Email addresses are expected to be unique in iPaaS.com, and duplicate email addresses across records can cause sync failures.

What this means for you: Make sure each customer and contact carries a unique email address before relying on the integration in production. If two records share an email address, one of them may fail to sync. When a transfer is rejected for this reason, the details are recorded in the iPaaS.com Dashboard under Integration Monitoring and in the Error Logs.

When inventory is captured from Business Central, both the available quantity and the on-hand quantity on the iPaaS.com inventory record are set from the same Business Central remaining-quantity value at each location.

What this means for you: Available quantity and on-hand quantity will match on the captured inventory record. If your downstream process needs to distinguish reserved or committed quantities, account for the fact that both fields reflect the same remaining-quantity figure.

When orders and invoices are written into Business Central, the bill-to and ship-to address fields are populated from the iPaaS.com order's primary billing and primary shipping addresses, using the custom-address mode so the individual mapped address fields are applied. When an order has no address flagged as primary billing or primary shipping, those address fields are left unset.

What this means for you: Make sure each order carries a primary billing address and a primary shipping address in iPaaS.com so the full address is written. If you would rather Business Central apply the customer's own default address, the address mapping can be adjusted to use the default mode and leave the individual address fields unmapped.

The posted sales invoice family includes a dedicated handling for lines that are present on the iPaaS.com transaction but absent from the Business Central invoice payload for a transfer. Rather than dropping such a line, the integration captures it with its shipped quantity set to zero so partially invoiced and unshipped lines are represented on the iPaaS.com transaction. This behavior works together with the Update Non-Existing Invoice Lines preset.

What this means for you: This is intended behavior that preserves partially invoiced lines instead of losing them. Confirm the Update Non-Existing Invoice Lines preset is configured as you intend for your invoice scenario so these lines are added to the correct iPaaS.com transaction.

Several values written into Business Central are validated against records that must already exist in your Business Central company. These include posting groups, payment terms codes, tax area and country/region codes, currency codes, salesperson codes, customer payment journals, general-ledger account numbers, and location codes. Business Central rejects a transfer that references a value it cannot find.

What this means for you: Confirm that every referenced code and account exists in your Business Central company before the first transfer. In addition, Business Central enforces customer, order, and invoice field requirements through your company configuration rather than through a public API specification, so subscribers or their MiSP should validate the required fields in a staging environment before relying on the integration in production.

Several collections ship with example or template values intended as a starting point, not as production-ready settings. These include the customer posting group, general business posting group, payment terms, and tax area on the customer-update flow; the currency code, salesperson, payment terms, journal, general-ledger account numbers, and location codes on the posted-invoice flow; the excluded-SKU and status-lookup values used when writing orders and invoices; and the company enrichment values, including the custom fields that carry secondary contact details and Business Central identifiers, on the company and company-hierarchy captures.

What this means for you: Before relying on the integration in production, subscribers or their MiSP must review each of these mappings and replace the example values with values that are valid for their own Business Central company and iPaaS.com configuration. Where a mapping records a value into an iPaaS.com custom field — for example, the company enrichment custom fields or a contact's extended values — confirm that the matching custom field already exists in iPaaS.com before the transfer runs, or that value is not stored. Validate the full configuration in a staging environment first.

Posting an invoice in Business Central depends on Business Central's own posting setup. Do not configure a balancing account on the payment methods used by the integration: when a balancing account is set, Business Central automatically creates a balancing entry during posting, which auto-applies and closes the payment and prevents the integration from linking it to the invoice. If a location has bin-mandatory enabled, every item line must have a bin defined, or invoice posting fails. When invoice totals do not match because only the subtotal is mapped, configure tax in Business Central so taxes reconcile correctly.

What this means for you: Align the Business Central posting setup with the integration's expectations before posting invoices: leave balancing accounts off the relevant payment methods, assign default bins (or use a non-bin location) where bins are mandatory, and confirm the tax setup with your finance team. Subscribers or their MiSP can contact iPaaS.com Support for help confirming these settings.

The integration reads and writes Business Central data through Business Central Web Services. Each entity the integration touches — customers, contacts, companies, items, item inventory, locations, sales orders and their lines, sales shipments, and sales invoices — requires the corresponding Web Service to be enabled in Business Central. When custom fields are mapped, the relevant Web Service must be customized to expose or accept those fields.

At the time this documentation was written, some flows additionally require specific fields to be exposed on the Web Service response before they will work:

What this means for you: Enable the required Web Services in Business Central as part of installation, and — where you use sales order or company relationship transfers — ensure the additional fields above are exposed on the corresponding Web Service. The integration cannot read or write an entity whose Web Service is not enabled, or a flow whose required field is not exposed. Subscribers or their MiSP can contact iPaaS.com Support for assistance configuring Business Central Web Services.

When an order or invoice is written into Business Central, the integration first resolves the records that order or invoice depends on. If the customer or company tied to the transaction is not yet linked to a Business Central record, the integration transfers it into Business Central before writing the transaction; if that dependency cannot be created, the transaction is not written. For each order line, a missing product is transferred into Business Central first, and existing records are matched and linked rather than duplicated. Similarly, when company hierarchy is enabled, a missing parent company is brought into iPaaS.com before its hierarchy link is recorded.

What this means for you: You generally do not need to pre-stage every dependency manually — the integration brings missing customers, companies, and products across as part of the transaction. However, a transaction will not be written if a required dependency cannot be created, so confirm that the underlying customers, companies, and products are valid and transferable. When the integration links to an existing record but cannot complete the link, the details are recorded in the iPaaS.com Dashboard under Integration Monitoring and in the Error Logs.

This article covers twenty-two known limitations of the Microsoft Dynamics 365 Business Central integration, grouped by sync direction and triggers, entity-specific constraints, field and value handling, implementation-time configuration, and automatic prerequisite dependencies. For the detailed behavior of any individual data flow, see the mapping collection descriptions and mapping documentation for that entity in the Help Center.