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-10-21, the integration has been validated against a live Acumatica sandbox using Contract-Based REST API endpoint version 22.200.001, with end-to-end transfers of Customers in both directions, Customer Companies and Contacts with their addresses into iPaaS.com, Sales Orders with their addresses, lines, taxes, and payments in both directions, standalone Tracking Numbers into Acumatica, and Stock Items and Warehouses into iPaaS.com. Subscribers should still validate end-to-end transfers in a staging environment with their own configuration 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.

Use an Acumatica user dedicated to the integration, so that people and other tools do not use up the sessions available to the integration's user.

Keep enough license capacity for every Acumatica subscription and any other API tools you run.

An unused session is released when its access token expires (about one hour). Restarting the Acumatica site from the Apply Updates form (screen SM203510) releases all sessions immediately, but it also signs out every Acumatica user, so use it with care.

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.

Customer Company (an Acumatica customer account captured as an iPaaS.com Company) and its child Customer Company Address capture TO iPaaS.com only. Contacts (captured as iPaaS.com Customers) and their address and Company relationship children also capture TO iPaaS.com only. There is no path that writes a company or a contact back into Acumatica.

Sales Order transfers in both directions through separate collections. Sales orders and their Sales Order Line, Sales Order Address, Sales Order Payment, Sales Order Tax, and Sales Order Tracking Number children write FROM iPaaS.com into Acumatica; Acumatica sales orders of order type SO, with their line, address, tax, and payment children, are captured TO iPaaS.com as transactions (see Sales Orders Captured to iPaaS.com).

AR Invoice (AR invoices, credit memos and debit memos) and its AR Invoice Line, AR Invoice Tax, and AR Invoice Payment children capture TO iPaaS.com only. There is no path that writes AR documents into 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.

An update from iPaaS.com overwrites every mapped field with the value the iPaaS.com record holds — including clearing the Acumatica value when the mapped iPaaS.com value is blank. Live testing confirmed this: a field that is mapped but empty on the iPaaS.com side replaces the existing Acumatica value with an empty value rather than leaving it in place. Treat every mapped field as fully owned by iPaaS.com on each update.

Fields that are not mapped are left untouched. A field with no mapping is not included in the write, so its existing Acumatica value is preserved. Managing a value directly in Acumatica is only safe when that field is not mapped in the update collection.

Do not rely on Acumatica-entered values for any field that is mapped and may be blank on the iPaaS.com side. The next update will overwrite or clear it. To keep a value that subscribers maintain directly in Acumatica (for example, a customer's credit terms or customer class), either leave that field unmapped in the update, or split the shipped combined add-and-update 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.

Customers are matched by CustomerID; the iPaaS.com record must map to a stable Acumatica CustomerID. An Acumatica customer account or contact that is not linked yet is linked to an existing, unlinked iPaaS.com Customer with the same email. Email is the only match: it is never matched by customer number (its Customer ID or Contact ID), so it cannot take over an unrelated iPaaS.com Customer that happens to have that number.

Customer Companies are linked by Customer ID; an account that is not linked yet is linked to an existing, unlinked iPaaS.com Company with the same name.

Sales Orders written to Acumatica, 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, taxes by their link (the Acumatica RecordID and row id of the tax row), so an update changes the same tax rows; a tax added to the iPaaS.com transaction after the order was created is not written to it, and tracking by tracking number.

Sales Orders captured to iPaaS.com are linked automatically: an order that is not linked yet is linked to the one existing, unlinked iPaaS.com Transaction of type Order with the same order number. The children of an existing Transaction are linked to its matching records: lines by SKU (then quantity and line number), addresses by their role (bill-to to the primary billing address, ship-to to the primary shipping address), taxes by Authority, and payments by Method (then amount).

AR invoices, credit memos and debit memos captured to iPaaS.com are linked by their reference number. A document that is not linked yet is linked to the one existing, unlinked iPaaS.com Transaction of the same type (Invoice, or Return for a credit memo) with the same number; its lines are matched by SKU, taxes by Authority, and payments by amount and method.

Stock Items are matched by SKU, Warehouses by Warehouse ID, and Tracking Numbers by their resolved parent transaction and tracking number.

Capture (TO iPaaS.com) collections are polling-based. Customer, Customer Company, Contact, Stock Item, Sales Order, AR Invoice, and Transaction Tracking Number are captured on a recurring poll cadence and can also be captured on demand with a Manual Sync; contacts are read by the customer poll, straight after the customer accounts. Warehouse capture has no automatic poll trigger; it runs through Manual Sync or a bulk Initialization, so subscribers run it on the cadence appropriate to how often warehouses change 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.

The first sales order poll does not pull existing orders. On a subscription with no earlier order poll time, the first poll only records its start time; orders that already exist in Acumatica are captured once they change, or with a Manual Sync of their order type and number (for example SO|000080).

The first AR invoice poll does not pull existing documents. AR invoices keep their own poll time; on a subscription with no earlier invoice poll time, the first invoice poll only records its start time, and documents that already exist are captured once they change, or with a Manual Sync of their document type and reference number (for example Invoice|000002).

Orders written to Acumatica are not sent straight back. The first poll or Manual Sync that finds an order written by Add/Update Acumatica Sales Order FROM iPaaS.com within about 20 minutes of the write does not capture it again; a change made in Acumatica after that is captured as usual (see Sales Orders Captured to iPaaS.com).

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.

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, in both directions for the line, address, payment, and tax collections.

AR Invoice Line, AR Invoice Tax, and AR Invoice Payment move only with their parent AR invoice, credit memo or debit memo.

Stock Item Warehouse Detail moves only with its parent Stock Item.

Customer Company Address moves only with its parent Customer Company.

Contact Address and Contact Relationship move only with their parent contact.

At least one valid line is required. An order with no line items cannot be written. A line whose product SKU does not exist in iPaaS.com (and as an Acumatica Stock Item), or whose shipping method does not exist in iPaaS.com, is skipped by the mapping filter without logging an error; if every line is skipped this way, the order arrives with no line items and is rejected (Error Messages code ACUM-VALD-1001).

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 postal codes must match the address's country. Acumatica checks each order address's postal code against its country; a malformed postal code rejects the order ("The entered code doesn't match the required expression"). A missing postal code is not sent, and the order address keeps the postal code Acumatica already holds for it (on a new order, the postal code of the customer's address).

Payment method names must match Acumatica. Each payment's method name on iPaaS.com is passed to Acumatica as the Payment Method ID, so it must exactly match a Payment Method configured in Acumatica (screen CA2040PL) that has a Cash Account; for example, an iPaaS.com payment with the method WEBCC is recorded against the Acumatica Payment Method WEBCC. Source systems that use other names (for example, Credit Card) need a Lookup Translation on the PaymentMethod mapping. A payment whose method does not resolve is rejected.

The iPaaS.com tax is recorded on new orders. The shipped IsTaxValid mapping asserts Acumatica's tax override when an order is created, so Acumatica keeps the tax amounts from iPaaS.com instead of calculating its own; on updates, the existing tax details are updated with the iPaaS.com amounts. 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. If the mapping is changed so that Acumatica calculates tax, a payment applied to the order cannot exceed the order total Acumatica calculates.

Kit and template item expansion is not supported. Each iPaaS.com line is written as a single order line.

Transfer sales orders once their lines are final. Changes to the quantity, price, or other fields of an existing line update the iPaaS.com transaction, but a change to the order's set of lines is not fully carried: a line removed from the Acumatica order after it has transferred stays on the iPaaS.com transaction, and a line added later can be written onto the transaction line of a removed line instead of being added as a new line. Orders are often passed on from iPaaS.com to other systems that do not accept later edits, so capture an order when its lines no longer change, for example by adding a Status condition to the Add/Update Acumatica Sales Order TO iPaaS.com mapping filter (the OrderType condition must stay in place).

An edit made right after iPaaS.com writes an order waits for the next change. When Add/Update Acumatica Sales Order FROM iPaaS.com creates or updates an order, iPaaS.com remembers that write for about 20 minutes, and the first poll or Manual Sync that finds the order in that time is treated as the write coming back: the order is not sent to iPaaS.com, nothing changes on its transaction, and no error is logged. An edit made in Acumatica before then is skipped with it and reaches the iPaaS.com transaction only when the order changes again. To send such an edit, wait about 20 minutes before running a Manual Sync of the order, or make a further change to the order in Acumatica after the next poll has run. Edits made after that poll are captured as usual.

Sales orders only. The shipped Add/Update Acumatica Sales Order TO iPaaS.com filter captures order type SO only; invoices, quotes, returns, and other order types are not captured unless the subscriber adds their order type to the filter.

The order's business account is transferred first. When an order's business account is not yet in iPaaS.com, it is transferred first through Add/Update Acumatica Customer TO iPaaS.com or Add/Update Acumatica Company TO iPaaS.com, as their filters decide. When neither captures it, the order is captured without a customer or Company, with the email of its bill-to contact (or else of its ship-to contact); iPaaS.com rejects a transaction that has no customer, no Company, and no email (VALD-1002).

Order lines need iPaaS.com products. Every SKU on a captured order's lines must exist as a product in iPaaS.com, or iPaaS.com rejects the transaction and the whole order is not captured. Transfer the stock items first through Add/Update Acumatica Stock Item TO iPaaS.com.

Payment methods must exist in iPaaS.com. Every Acumatica payment method used on captured orders must exist in iPaaS.com as a Payment Method with the same name, or be translated to one by the Method mapping. A new payment with a method iPaaS.com does not have is rejected with VALD-1036, and the whole order is not captured.

Transaction numbers must be unique in iPaaS.com. A sales order or AR document is never linked to a Transaction of another type with its number, and iPaaS.com rejects it as a duplicate transaction number (NFND-1029) instead. The error appears in Dashboard / Integration Monitoring / Error Logs, and the document is not captured while another Transaction type holds its number.

Invoice lines need iPaaS.com products. Every inventory item on a captured AR invoice, credit memo or debit memo line must exist as a product in iPaaS.com with the same SKU, or iPaaS.com rejects the transaction (NFND-1003) and the whole document is not captured. AR invoice lines usually carry non-stock items, which Add/Update Acumatica Stock Item TO iPaaS.com does not transfer, so create those products in iPaaS.com before documents that use them are captured.

Lines with no inventory item use a placeholder SKU. A free-text line, such as a service charge, a flat fee, freight or a refunded fee, is sent with the SKU MISC-CHARGE, which must exist as a product in iPaaS.com; its GL account is kept in the Transaction Line custom field Acumatica Account. The Sku mapping can send a different placeholder per GL account.

Payment methods must exist in iPaaS.com. Every Acumatica payment method used on a payment applied to a captured invoice must exist in iPaaS.com as a Payment Method with the same name, and a credit memo applied to an invoice is sent with the method Credit Memo, which must exist too. A payment with a method iPaaS.com does not have is rejected with VALD-1036, and the whole invoice is not captured. Add the payment methods in iPaaS.com before invoices with payments are captured.

The business account must be captured. The AR Invoice collection maps no email, so iPaaS.com rejects a document whose business account neither Add/Update Acumatica Customer TO iPaaS.com nor Add/Update Acumatica Company TO iPaaS.com captures (VALD-1002).

Transaction numbers must be unique in iPaaS.com. A sales order or AR document is never linked to a Transaction of another type with its number, and iPaaS.com rejects it as a duplicate transaction number (NFND-1029) instead. The error appears in Dashboard / Integration Monitoring / Error Logs, and the document is not captured while another Transaction type holds its number.

Reference numbers must be unique across document types. A document is linked by its reference number alone, so an invoice and a credit memo with the same number would update the same Transaction. Keep one numbering sequence, or non-overlapping sequences, for the AR document types.

Total and balance. The Transaction Total is the document total; the amount still owed after payments is kept in the Transaction custom field Acumatica Balance.

Captured, not written back. AR documents are captured from Acumatica only. Add/Update Acumatica Sales Order FROM iPaaS.com writes only Transactions of type Order, so captured invoices are not written back to Acumatica.

Every order needs an Acumatica customer account. Acumatica places each sales order on a customer account. It does not derive the account from a contact, and it rejects a contact that belongs to a different account. The shipped CustomerId mapping looks for the account in this order: the order's iPaaS.com Company; then its Customer (a Customer that came from an Acumatica contact uses that contact's business account); then the account whose main, primary, billing, or shipping contact has the order's email; and finally the business account of the one Acumatica contact with that email.

A contact needs a customer business account. An order stops with ACUM-BIZL-1010 when it comes from a contact that has no business account, or whose business account is not a customer (for example, a vendor).

Companies are not written to Acumatica. There is no Company FROM iPaaS.com flow. An iPaaS.com Company is linked to Acumatica only when its Acumatica account transfers TO iPaaS.com. An order with an unlinked Company is placed through its Customer or its email if either resolves to an account. Otherwise it stops with ACUM-BIZL-1011, and no Acumatica customer is created for an order with a Company.

The order's Company comes only from the transaction. The integration does not read a Customer's Company relationship in iPaaS.com. An order goes on a Company's account only when the transaction itself carries the Company. Take an order that carries only a Customer with no Acumatica link, whose email matches no Acumatica account or contact: that Customer is created as a new Acumatica customer account, even if it belongs to a Company in iPaaS.com.

A Company and a contact on the same order must agree. When an order carries both a Company and a Customer that came from a contact, it goes on the Company's account with that contact. If the contact belongs to a different Acumatica account, Acumatica rejects the order.

Contact email matching needs a unique email. An order found by a contact's email resolves only when exactly one Acumatica contact has that email. When several contacts share it, none is picked.

Orders with neither a Company nor a Customer are left to the mapping. If the mapping resolves no account, Acumatica rejects the order with "'CustomerID' cannot be empty."

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.

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.

Only some contact fields are written. Each address is written as a customer contact with its address lines, company, display, full and last name, and phone (Phone1); the contact's email is the customer's email. The other contact fields the address carries are captured TO iPaaS.com only and are not written by Add/Update Acumatica Customer Address FROM iPaaS.com, so a mapping to them has no effect: Attention, Email (of the address), Fax, JobTitle, MiddleName, Phone1Type, Phone2, Phone2Type, Title and WebSite. ContactID is set by Acumatica. Maintain these fields in Acumatica.

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.

The subscriber decides which accounts are Companies. Add/Update Acumatica Customer TO iPaaS.com and Add/Update Acumatica Company TO iPaaS.com both read the Acumatica customer account, and both polls return every changed account. The integration does not decide which accounts are companies: the two collections' mapping filters do. Base the split on a value that is set on purpose in Acumatica, such as the Customer Class, and make the two filters complementary so each account matches exactly one collection. Do not base it on anything that changes as users work, such as whether the account has contacts.

With the shipped filters, accounts become Companies only in the customer class COMPANY. The two collections come with a split on the customer class COMPANY: until accounts are placed in a customer class with that name in Acumatica, every account is transferred as an iPaaS.com Customer and none as a Company. To split on a different value, change both filters together. Give the class the defaults Acumatica requires on its accounts, such as a statement cycle, because Acumatica applies them when an account is moved to the class.

The Customer filter can only use values contacts also carry. The Customer collection's filter is evaluated for Acumatica contacts too, so a condition on an account value that contacts do not have makes every contact transfer fail with a filter error, however the condition is written. Contacts carry the Customer Class of their business account, which is why the customer class is the value to split on.

Changing the split later does not move existing records. When the filters change so that an account moves from one collection to the other, the record the account had in iPaaS.com is not removed or converted; it stays as it was, and the account is transferred as the other record type from then on.

The first company poll reads every account. The first company poll on a subscription, when no earlier company poll time has been saved, reads every customer account in Acumatica; the filter then transfers only the accounts it takes as companies.

Company names must be unique. iPaaS.com does not allow two Customer Companies with the same name, so two Acumatica customers with the same name cannot both be transferred as companies; the second fails with the iPaaS.com error NFND-1029.

Contacts of accounts that are not Companies have no Company relationship. When a contact's business account is not taken as a company by the filter of Add/Update Acumatica Company TO iPaaS.com (for example, an account kept as an iPaaS.com Customer), the contact is transferred as an iPaaS.com Customer without a relationship.

Contacts of non-customer accounts are transferred. A contact whose business account is not an Acumatica customer (for example, a vendor account) is transferred as an iPaaS.com Customer with no Company relationship. The contact record carries no account type, so subscribers who do not want these contacts assign them a contact class in Acumatica (for example, VENDOR) and exclude that class in the Add/Update Acumatica Contact TO iPaaS.com collection filter: RecordType == "Contact" && ContactClass != "VENDOR". Restrict any other unwanted contacts the same way.

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.

Financial Terms ships a placeholder credit terms code on the Sales Order. Replace it with a single-installment credit term that exists in Acumatica.

Customer tax zone (the Sales Order CustomerTaxZone mapping) and tax code (the Sales Order Tax TaxID mapping) ship formulas that return the first tax zone and the first tax code configured in Acumatica. Replace them with the tax zone and tax code intended for imported orders.

Payment method (the Sales Order Payment PaymentMethod mapping) translates the example name Test Gateway to the Acumatica Payment Method WEBCC. Replace the example with the subscriber's payment method names and their Acumatica Payment Method IDs.

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.

Deletes are not propagated. Removing a record in one system is not propagated as a delete into the other through any collection.

Purchase Orders are not supported, and AR invoices are captured only. Purchase orders are not registered for transfer. AR invoices, credit memos and debit memos are captured from Acumatica into iPaaS.com; they are not written from iPaaS.com into Acumatica.

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 the payment method names used on iPaaS.com must match them or be translated by the mapping.

iPaaS.com <> Acumatica: Background

Acumatica Installation Instructions

Acumatica Connections and Settings

Acumatica Mapping Functions

Acumatica API Endpoints

Acumatica Error Messages