This article lists the known limitations and out-of-scope behaviors of the iPaaS.com Acumatica integration. These constraints apply to all subscribers and reflect how the integration behaves at the time this documentation was written. Subscribers or their MiSP should review these limitations before relying on the integration in production and should validate any uncertain behavior in a staging environment first.

When a transfer cannot complete because of one of the constraints below, the failure is recorded in iPaaS.com under Dashboard / Integration Monitoring / Error Logs, where the affected record and the reason are available for review.

Platform Scope and Tested Versions

The integration communicates with Acumatica through the Acumatica Contract-Based REST API (the Default endpoint). Acumatica installations that do not expose this API, or that restrict the entities the integration relies on, are not supported.
As of 2026-06-26, the integration has been verified by code review only. It has not yet been validated against a live Acumatica sandbox, and live round-trip transfers in each direction have not yet been executed. Subscribers should validate end-to-end transfers in a staging environment before relying on the integration in production.
Each entity is supported only in the direction the integration implements it. Directionality is fixed per entity and cannot be reversed through configuration (see Directionality Is Fixed Per Entity).
This integration is built for the Acumatica Contract-Based REST API described above. It is not built for other Acumatica product lines or materially different API versions: if Acumatica releases a separate product line, or an API version that changes the entities or behavior the integration relies on, this integration will not automatically support it without further development.

Directionality Is Fixed Per Entity

Each entity moves in a fixed direction. There is no configuration option to reverse the direction of a collection.

Customer transfers in both directions, through separate "TO iPaaS.com" (capture) and "FROM iPaaS.com" (write) collections. Customer Address moves only as a child of its parent Customer in either direction.
Sales Order and all of its children — Sales Order Line, Sales Order Address, Sales Order Payment, Sales Order Tax, and Sales Order Tracking Number — write FROM iPaaS.com into Acumatica only. There is no path that captures a Sales Order or its children back out of Acumatica.
Stock Item (product) and its child Stock Item Warehouse Detail, and Warehouse, capture TO iPaaS.com only (poll/pull). There is no path that writes these records back into Acumatica.
Transaction Tracking Number transfers in both directions through its standalone Add and Update collections, and also moves as a child of a Sales Order in the outbound direction.

Because Customer and Transaction Tracking Number can move in both directions, enabling the inbound and outbound collections for the same entity at the same time can create a loop, where a change captured into iPaaS.com triggers a write back into Acumatica that re-triggers the capture. Before enabling both directions for the same entity, review and customize the mapping collection filters to prevent circular updates.

Writes Are Upserts — Blank Fields Are Preserved, Not Cleared

Every write into Acumatica is an upsert: a record with the supplied identifier is created if it does not exist and updated if it does. There is no separate create-only path, and there is no field-clearing write.

A mapped field left blank or omitted on an update is preserved on the existing Acumatica record, not cleared. To change a value, write the new value; to clear a value, write an explicit empty value rather than omitting the mapping, or change it in Acumatica directly.
Because the combined add-and-update mappings shipped with the templates treat iPaaS.com as the source of truth for all mapped fields, an update from iPaaS.com overwrites the mapped fields on the Acumatica record. Subscribers who want to manage certain values directly in Acumatica (for example, a customer's credit terms or customer class) should split the mappings into a separate add-only collection and an update-only collection, limiting the update collection to only the fields iPaaS.com should own. Decide this before go-live.

No Collision Handling

Collision handling is not offered for any Acumatica entity, and no collision-resolution method is selectable. Repeated transfers of the same record are de-duplicated by external-id linking, not by collision detection:

Customers are matched by CustomerID; the iPaaS.com record must map to a stable Acumatica CustomerID.
Sales Orders and their lines are de-duplicated only when the Sales Order Duplicate Checking subscription setting is enabled; lines are matched by SKU and ordered quantity, tax details positionally, and tracking by tracking number.
Stock Items are matched by SKU, Warehouses by Warehouse ID, and Tracking Numbers by their resolved parent transaction and tracking number.

Triggers Are Polling-Based — No External Webhooks

The integration is not notified by Acumatica when a record changes. Acumatica does not push changes to the integration.

Capture (TO iPaaS.com) collections are polling-based. Customer and Stock Item are captured on a recurring poll cadence and can also be captured on demand with a Manual Sync. Warehouse and the standalone Transaction Tracking Number captures run through Manual Sync only — they have no automatic poll trigger — so subscribers run them on the cadence appropriate to how often the underlying data changes in Acumatica.
Write (FROM iPaaS.com) collections are driven by Outbound Data Flow trigger subscriptions in iPaaS.com plus Manual Sync. There is no inbound webhook step from Acumatica.
Because capture is polling-based, a change in Acumatica is reflected in iPaaS.com on the next poll or Manual Sync rather than instantly.
Warehouse also supports a bulk Initialization (one-pass pull of all warehouses), which is useful when Location records need to be in place before related Product data is integrated.

Child Collections Cannot Run Independently

Several collections only move as children of a parent transfer and have no standalone Manual Sync. To transfer one, transfer its parent.

Customer Address (both directions) moves only with its parent Customer.
Sales Order Line, Sales Order Address, Sales Order Payment, Sales Order Tax, and Sales Order Tracking Number move only with their parent Sales Order.
Stock Item Warehouse Detail moves only with its parent Stock Item.

Sales Order Limitations

At least one valid line is required. An order with no line items, or whose only lines reference SKUs that do not exist as Acumatica Stock Items, cannot be written.
Only stock items are supported on order lines. Non-stock items are not supported and are not written to the order.
Shipments and invoices of the sales order are not supported. Generating or transferring shipments and invoices for the sales order from iPaaS.com is out of scope. Only the sales order itself — with its addresses, lines, payments, taxes, and tracking — is written.
Credit terms must use a single installment type. A multiple-installment credit term causes Acumatica to reject adding a payment to the order.
Manual order numbering must be enabled to honor the iPaaS.com order number. By default Acumatica auto-assigns its own sales order number and ignores the value supplied from iPaaS.com. To have Acumatica accept the iPaaS.com order number, manual sales order numbering must be configured in Acumatica (screen CS201010).
Order addresses accept numeric postal codes only. A postal code containing non-digit characters is written as empty so the order is not rejected for an invalid format.
One payment method by default. Without a translation or mapping formula, every imported order receives the same placeholder payment method. Payment methods are not read from Acumatica; they must be configured in Acumatica and assigned through the mapping.
Tax is recorded, not calculated. The integration records externally collected tax against an eligible tax code; it does not calculate tax in Acumatica. The applied tax code must be eligible for the tax category assigned to the order's products, and the customer tax zone must be configured.
Kit and template item expansion is not supported. Each iPaaS.com line is written as a single order line.

Sales Order Tracking and Shipment Limitations

Box and warehouse are required. A tracking transfer is rejected when either the BoxId or WarehouseId custom field is empty. Both the box and the warehouse must be configured in Acumatica.
Only Open shipments can be created. Shipments are created in the Open status; a shipment Acumatica would place in another status is rejected. The Hold Shipments on Entry option in Acumatica Sales Order Preferences must be deactivated.
Line-link reference is required for partial shipments. The iPaaS_LineItemId custom field must follow the form transaction identifier followed by transaction line identifier, so package contents are recorded against the correct order line.
Boxes, warehouses, and shipping methods are not created by the integration. They must already be configured in Acumatica (boxes and warehouses) or in iPaaS.com (shipping methods) before tracking transfers.
Inbound tracking requires a resolvable parent and an existing shipping method. A package that does not resolve to an existing iPaaS.com transaction is rejected, as is a package whose shipping method does not yet exist in iPaaS.com.
Declared value may be absent. Some Acumatica shipments do not carry a declared cost on the package, so the captured Cost may be empty.

Customer and Customer Address Limitations

One address per primary type. Only one address may be flagged primary contact, one primary billing, and one primary shipping. Flagging more than one address for the same type produces unpredictable contact assignment in Acumatica.
Customer name length. Acumatica limits the customer name to 50 characters by default; longer names are truncated unless the field is extended in Acumatica.
Customer Class and Statement Cycle must already exist in the subscriber's Acumatica installation; values that do not exist are rejected.
Statement-by-email requires a billing-contact email. When a send-by-email option (statements, invoices, or dunning letters) is enabled on the customer, Acumatica requires an email on the primary billing contact.
Country must match Acumatica's format (for example, US) on outbound addresses, or the address is rejected.
Partial addresses may not register. Acumatica stores a contact address only when its core fields (line 1, city, state, postal code, country) are present together.
Custom fields are not supported on the outbound Customer Address write path. A custom field configured there does not write to Acumatica. On the inbound side, the Acumatica Primary Contact designation is retained only when the corresponding custom field is configured in iPaaS.com.

Stock Item and Warehouse Limitations

Capture-only. Stock Items and Warehouses flow into iPaaS.com only; changes made in iPaaS.com are not written back to Acumatica.
SKU uniqueness dependency. A non-unique or empty Acumatica inventory ID prevents reliable matching to an iPaaS.com Product; two Stock Items that resolve to the same SKU update the same iPaaS.com Product.
Warehouse location dependency. Warehouse-level detail is captured only when the Acumatica warehouse name resolves to a configured iPaaS.com location; an unresolved name leaves that warehouse's detail uncaptured.
On-hand and available quantities share a source. Both the on-hand and available quantities on warehouse detail are populated from the Acumatica on-hand quantity; the integration does not subtract allocations to derive a separate available figure. Subscribers whose availability logic needs to distinguish the two should validate this in a staging environment.
Fixed product classification. Every captured product is assigned a fixed product type and tracking method, set by the integration rather than read from Acumatica.
Kit components and template/matrix items are captured as a single Product. A kit, template, or matrix Stock Item is captured into iPaaS.com as one Product; its individual components or variant items are not expanded into separate Products on capture.
Warehouse capture supports no custom fields and has no automatic trigger; only the warehouse identifier and description are captured, through Manual Sync.

Placeholder Defaults Must Be Replaced Before Go-Live

Several mappings ship with placeholder values that must be replaced with values configured in the subscriber's Acumatica installation before the integration is used in production:

Financial Terms ships a placeholder credit terms code on the Sales Order. Replace it with a single-installment credit term that exists in Acumatica.
Payment Method ships a placeholder method on Sales Order Payment. Replace it (or add a translation) with a method that exists in the subscriber's Acumatica Payment Methods configuration.
Tax codes, customer tax zones, customer classes, statement cycles, boxes, warehouses, and country codes referenced by the mappings must all exist in Acumatica before transfers will post.

Unsupported Entities and Operations

Deletes are not propagated. Removing a record in one system is not propagated as a delete into the other through any collection.
Connection validation is not performed before use. Subscribers should confirm the connection is configured and authorized correctly before relying on transfers.
Purchase Orders and Invoices are not supported. These entities are not registered for transfer and are not documented as supported, even though related fields may appear in configuration.
Categories are not transferred. Product categories are not captured or written by the integration.
Payment-method discovery is not supported. The integration does not read Acumatica payment methods; they must be configured in Acumatica and assigned through the mapping.

The eleven limitation areas above cover the constraints that most often affect production transfers. For the field-level technical detail behind each behavior — how individual records are matched, which fields are written, and what each collection captures or omits — refer to the per-collection mapping documentation and the collection descriptions for the entity you are working with.

Acumatica Known Limitations