Biz-Tech Services https://biz-techservices.com/ Ignite your business with us! Tue, 18 Aug 2026 23:54:41 +0000 en hourly 1 https://wordpress.org/?v=7.1 https://mlt1wwte1gj9.i.optimole.com/cb:O8Ue.e5e/w:32/h:32/q:mauto/g:sm/ig:avif/dpr:2/https://biz-techservices.com/wp-content/uploads/cropped-Biz-Tech-Services-Favicon-1.png Biz-Tech Services https://biz-techservices.com/ 32 32 How Salesforce CRM Data Flows into Acumatica ERP https://biz-techservices.com/archives/10368 Tue, 18 Aug 2026 23:54:41 +0000 https://biz-techservices.com/?p=10368 How Salesforce CRM Data Flows into Acumatica ERP Salesforce orders flow into Acumatica as sales orders through a connected store […]

The post How Salesforce CRM Data Flows into Acumatica ERP appeared first on Biz-Tech Services.

]]> How Salesforce CRM Data Flows into Acumatica ERP

Salesforce orders flow into Acumatica as sales orders through a connected store record, and updated order data flows back out to the CRM on demand. Salesforce is a Customer Relationship Management platform, or CRM, and Acumatica is an Enterprise Resource Planning system, or ERP. The Biz-Tech Services Salesforce Acumatica Connector is the bridge between them, moving orders, customers, contacts, items, price books and discounts across the gap so that sales, finance and inventory all work from the same numbers.

This article follows that path end to end: how the connection is established, how a Salesforce order becomes an Acumatica sales order, how customers and items are resolved along the way, how pricing and discounts are kept aligned, and how changes made in the ERP are pushed back out. Configuration is covered here only where a specific setting decides what happens at a handoff, because the settings are what make the flow behave one way rather than another.

What the Salesforce Connector for Acumatica Does

The Biz-Tech Services Salesforce Acumatica Connector is an integration product from Biz-Tech Services, Inc. that connects a Salesforce CRM org to an Acumatica ERP instance. It defines data synchronization, automates the workflows that move records between the two platforms, and keeps data flowing in both directions. On the ERP side it adds a Salesforce Store screen that holds the credentials and the rules for the integration, processing screens for importing orders and exporting customers, price books and discounts, and inquiry screens where the results of each transfer can be reviewed. The product must be installed on an Acumatica system carrying a PCSR PERP or SAAS license.

The Salesforce Data Flow at a Glance

Every record that crosses between the two systems follows the same broad path. These are the stages, in the order they occur:

1. The Salesforce Store screen holds the store code, its description, and the API credentials on the General Info tab that link the two systems.

2. The Test Credentials button under Actions in the screen header confirms the connection is valid before any data moves.

3. The Get Orders button on the Import Salesforce Orders screen retrieves orders dated after the value set in the Order Settings tab of the store.

4. Import or Import All turns the selected orders, or all displayed orders, into Acumatica sales orders of the configured Order Type.

5. During that import the connector resolves the customer and the items on the order, creating them in Acumatica or matching them to existing records, and applies the tax, payment and discount rules.

6. The resulting document can be opened from the Salesforce Orders Inquiry screen, which shows the original CRM detail alongside the SO number and SO status.

7. Customers, price books and discounts flow outbound through the Export Salesforce Customers screen and its counterparts for price books and discounts.

8. Order changes made in Acumatica flow back through the Sync Orders To Salesforce screen, updating the matching CRM order at both line and document level.

Stage One: Connecting Salesforce to Acumatica

Everything downstream depends on the Salesforce Store screen. The store code carries all the configuration and setup for the integration between the two systems, and the description field holds notes about what that store code represents. Underneath the code and description sit the tabs that govern the flow.

The General Info tab is where the API credentials that link the CRM with the ERP are entered. Once they are in place, the Test Credentials button in the header under Actions reports whether the credentials are correct. The Order Settings tab then defines how imported records behave: the order import process, order calculation, order type, import destination, order discount settings, payment methods and more. Because these settings are read at import time rather than at setup time, they are the switches that decide what each incoming Salesforce record turns into.

Inbound: How Salesforce Orders Become Acumatica Sales Orders

The Import Salesforce Orders screen is the transfer point for order data moving from the CRM platform into the ERP system. Pressing Get Orders retrieves the Salesforce orders related to the date set in the Order Settings tab of the store. The Import button brings in only the orders selected in the grid, while Import All brings in every order currently displayed.

Which Default Import Options Shape the Result

Several fields in Default Import Options determine the shape of the resulting document. Order Type indicates the document type the order should be imported into and placed as in Acumatica. Warehouse ID sets the default warehouse for the order. Last Imported Order Date displays the date of the last imported order, and that date is used the next time orders are fetched to decide which orders count as new, so it is the field that keeps repeat pulls from re-importing history. Last Imported Price Book Date works the same way for price books.

Enable File Import Process controls whether attachments travel with the order. When the checkbox is selected, the file is retrieved from the Salesforce order and copied into the workspace on the Sales Orders screen at import time. When it is cleared, the file is not retrieved with the order at all.

How Tax Is Calculated on an Imported Order

Tax options allow for alternative tax calculations based on how the tax option is set up. Selecting Use External enables the calculation of alternative taxes such as Avalara tax. Setting up the Customer Tax Zone, Tax ID and Tax Category instead allows for the import of similar taxes, such as those coming from Salesforce. The choice determines whether the tax figure on the imported order is calculated locally or carried over.

How Customers and Items Are Resolved During Import

An incoming Salesforce order is only useful if it lands on the right customer and the right inventory items. The connector resolves both during the import process.

Customer Creation and Address Handling

When the Import Customer checkbox is selected, a new customer is created in Acumatica during the order import process, using the email, the contact information and the selected customer class. When the checkbox is cleared, the system uses the default customer for every imported order instead, which keeps the customer list from growing with every CRM transaction.

The Override Billing Address Information and Override Shipping Address Information checkboxes decide which address ends up on the sales order. When they are selected, the import process overrides the customer addresses and sets the Salesforce order address on the sales order.

Item Matching and Product Creation

Item Settings governs how products are resolved. When the Import Item checkbox is selected, new items are created in Acumatica based on the configured settings as items are imported from Salesforce. When it is not selected, the program prohibits the import and creation of items unless the corresponding items already exist there. In that case the system searches for the Inventory CD using the Salesforce Product SKU: if it is found, that item is retrieved; if it is not, the error message “The item {0} does not exist in the system” is displayed and the record stops there. Add Items in Inventory Sync enables item synchronization, and Use Numbering Sequence for Product ID Generation makes the system automatically generate a unique product ID for each new product from a predefined numbering sequence.

How Payments Ride Along With the Order

Default Payment Options controls the payment side of the import. Skip Salesforce Payment imports the order without a payment when selected. Payment Method sets the payment method applied during the order import process, and Payment Type determines the payment type of the imported order. Release Payment during Order Import releases the payment as part of that same import. Selecting the Use Cross Ref for Payment checkbox on the Order Settings tab enables payments through cross-reference, and when cross-reference is used for payment the payment must not be skipped. Cross-reference options more generally let your business link and map Acumatica and Salesforce values such as Payment, Country or Ship Via, with each option enabled by its checkbox and mapped on the Cross-Reference tab.

How Pricing and Discounts Stay Aligned

Prices reach the ERP through price books. Selecting the Last Imported Price Book Date on the Order Settings tab lets you load Salesforce price books into the Price Book Details tab based on that date. Each ID listed in that tab is a hyperlink to the Salesforce Price Books inquiry screen, where the list price can be changed and item lines added or deleted.

The Salesforce Price Books screen is also where synced products are added to a price book and the list price is defined manually. Selecting a preferred price book ID and clicking Get All Products in the Actions menu retrieves and displays every item in that price book. Two ordering rules matter here: items must be included in the standard price book before they are added to another price book, and if an item already exists in a price book it must be brought into Acumatica by importing an order, during which the item is automatically added to the corresponding price book.

Discounts follow their own path. When the Salesforce Synced checkbox is cleared on the Acumatica Discounts screen, the setup discount code appears on the Export Salesforce Discounts screen, where it can be created or updated and then used during order creation. Both line and document discount types are supported.

Outbound: Sending Acumatica Data Back to Salesforce

The flow does not end when an order lands in the ERP. Four screens move data in the other direction.

Exporting Customers and Contacts

The Export Salesforce Customers screen creates and updates Acumatica customers in Salesforce. Load Acumatica Customers loads and displays all of them, and the Export or Export All button creates or updates the selected customers or all of them in the CRM. If a customer has a primary contact, that primary contact is also created as a Contact during the customer creation process. Note that the export creates the primary contact only once and does not update it afterward, so later contact corrections do not travel.

Exporting Price Books

The Export Salesforce Price Books screen displays all the price books that have been loaded and are shown in the Price Book Details tab of the store screen. Process or Process All adds or updates products in the selected price books or in all of them. Only items that have been updated or changed are exported; unmodified items are not sent, which keeps each run small.

Syncing Order Changes Back to the CRM

The Sync Orders To Salesforce screen is where an order that came in from the CRM, was updated in Acumatica, and now needs to be pushed back gets processed. Updates are supported at both the order line level and the order document level. At the line level it updates the line description, discount code and discounted amount, and lines can be added and deleted. At the document level it updates the shipping and billing addresses, plus country, order date, order description, order total, freight amount, discount amount and tax amount. After changing that data, selecting the order and syncing it updates the CRM record to match. The screen also retrieves internal notes from Salesforce and displays them in the sales order Notes workspace, where they are read-only.

One filter governs what appears here: only modified orders with a status of On Hold or Open are displayed on this screen. An order that has moved past those statuses will not be listed, which is the first thing to check when an expected order is missing.

Where to Monitor Salesforce Results in Acumatica

Every stage of the flow leaves a visible trace. These are the exact places to look when you need to confirm that a record moved:

1. Import Salesforce Orders screen: the grid of orders retrieved by Get Orders, before and after Import or Import All is pressed.

2. Salesforce Orders Inquiry screen: reached by clicking the Order ID hyperlink on the import screen, showing the initial order details.

3. SO number and SO status on that inquiry screen: proof that the CRM order became an Acumatica sales order, and where that order now stands.

4. The workspace on the Sales Orders screen: holds the file copied from the Salesforce order when Enable File Import Process is selected.

5. The Notes workspace on the sales order: holds the internal notes retrieved from the CRM, which are uneditable.

6. Salesforce Info tab on the Customers screen: a generated ID plus a selected Salesforce customer checkbox means the record is a synced customer.

7. The Contacts screen: the same ID and checkbox logic applies to the primary contact.

8. The Export Salesforce Customers processing page: displays the Account ID and the last sync date for records already synced.

9. Item Details tab of the store screen: the synced item Salesforce ID, product code, product name, price and weight, populated by Load Acumatica Items, Sync to Salesforce and Sync all from Salesforce.

10. Price Book Details tab of the store screen: the price books loaded from the CRM, each ID linking through to the Salesforce Price Books inquiry screen.

11. Last Imported Order Date and Last Imported Price Book Date on the Order Settings tab: the watermark that decides what the next fetch pulls.

12. Salesforce Synced checkbox on the Discounts screen: cleared means the code is still waiting on the Export Salesforce Discounts screen.

Salesforce Acumatica Integration: Frequently Asked Questions

How do Salesforce orders get into Acumatica?

Press Get Orders on the Import Salesforce Orders screen. The connector retrieves the orders related to the date set in the Order Settings tab of the store and lists them in the grid. Then use Import to bring in only the orders you selected, or Import All to bring in every order displayed.

Does the connector create customers in Acumatica automatically?

Only if you tell it to. With the Import Customer checkbox selected, a new customer is created during the order import process with email, contact information and the selected customer class. With the checkbox cleared, every imported Salesforce order is placed on the default customer instead.

Can changes made in Acumatica be sent back to Salesforce?

Yes, through the Sync Orders To Salesforce screen. It updates the order at both line and document level, covering line description, discount code and discounted amount, added and deleted lines, shipping and billing addresses, country, order date, order description, order total, freight amount, discount amount and tax amount.

Why do I get “The item does not exist in the system” when importing a Salesforce order?

That message appears when the Import Item checkbox is not selected and the product on the order has no match in Acumatica. The system searches for the Inventory CD using the Salesforce Product SKU, and when nothing is found it cannot create the item on its own. Either create the item in Acumatica first, or select Import Item so new items are created from the configured settings during import.

Why is my modified order missing from the Sync Orders To Salesforce screen?

That screen only displays modified orders with a status of On Hold or Open. If the sales order has moved to another status, it will not appear in the list regardless of the changes made to it. Check the SO status on the Salesforce Orders Inquiry screen first.

Why does my imported order have no payment on it?

Check Skip Salesforce Payment in Default Payment Options, because when that checkbox is selected the order is imported without payment. Also check whether Use Cross Ref for Payment is selected on the Order Settings tab: when payments run through cross-reference, the payment must not be skipped, so the two settings have to agree.

Why can I not add a product to a Salesforce price book?

Items must be included in the standard price book before they can be added to another price book. If the item already exists in a price book, it has to be brought into Acumatica by importing an order first, and during that import the item is automatically added to the corresponding price book.

How do I confirm a customer is already synced?

Open the Customers screen and look at the Salesforce Info tab. When the Salesforce customer checkbox is selected and an ID has been generated there, the record is synced. The export processing page also shows the Account ID and the last sync date for customers that have already been sent across.

Work With the Biz-Tech Services Salesforce Connector

The data flow into Acumatica is a single continuous path: credentials on the Salesforce Store screen, orders pulled by Get Orders, customers and items resolved during import, tax and payment applied from the store settings, results visible on the Salesforce Orders Inquiry screen and on the sales order itself, and updates pushed back out through the Sync Orders To Salesforce and export screens. Knowing which screen owns which stage is what makes the integration straightforward to run day to day.

If your business runs Salesforce alongside Acumatica and wants that flow set up, tuned and monitored properly, the Biz-Tech Services Salesforce Acumatica Connector is built for exactly that. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration.

The post How Salesforce CRM Data Flows into Acumatica ERP appeared first on Biz-Tech Services.

]]> How PayPal Payment Data Flows into Acumatica ERP https://biz-techservices.com/archives/10361 Mon, 17 Aug 2026 23:52:51 +0000 https://biz-techservices.com/?p=10361 How PayPal Payment Data Flows into Acumatica ERP The Biz-Tech Services Acumatica PayPal Integration for ERP moves payment data along […]

The post How PayPal Payment Data Flows into Acumatica ERP appeared first on Biz-Tech Services.

]]> How PayPal Payment Data Flows into Acumatica ERP

The Biz-Tech Services Acumatica PayPal Integration for ERP moves payment data along one clear path: an Accounts Receivable (AR) Payment created in Acumatica sends a live invoice to your customer through PayPal, and every status check pulls that invoice state back onto the same payment record to release it, void it, or update the amount collected. Nothing is guessed and nothing is duplicated — the Acumatica payment is the anchor, and the provider is the source of truth for whether money actually arrived.

Understanding that round trip is what makes the product easy to run day to day. This article traces the flow in the order records actually travel: credentials go in first, a payment request goes out, the resulting status comes back into Acumatica, and the outcome lands on fields your accounting team can filter, report on, and reconcile. The product described here is the Biz-Tech Services PayPal Acumatica Integrator for Acumatica ERP, built by Biz-Tech Services, Inc.

What the PayPal Integration for Acumatica Does

The Biz-Tech Services Acumatica PayPal connector is an Acumatica ERP customization that lets your business send payment invoices directly to customers from inside Acumatica, monitor payment status, and update payment records automatically when money is received, refunded, or cancelled. Invoices are created and sent through the PayPal invoicing Application Programming Interface, or API. Status updates are pulled on demand or processed in bulk, and the resulting accounting entries — release, void, partial collection — are handled by the customization rather than by hand.

Because the Biz-Tech Services PayPal Acumatica connector lives inside Acumatica, your team never has to leave the system to manage this billing. The Accounts Receivable and Sales Orders modules are both required, and on the provider side you need a PayPal Business account, since Personal accounts do not support the invoicing API. The Acumatica server must also be able to reach api-m.paypal.com, or the sandbox endpoint, over HTTPS on port 443. The package itself is published like any other customization from the Customization Projects screen (SM204505).

The PayPal Data Flow at a Glance

Before looking at individual screens, it helps to see the whole path a record takes. Every transaction handled by the Biz-Tech Services Acumatica PayPall integrator follows the same sequence, no matter which screen starts it:

1. Credentials in: a Payment Method in Acumatica (CA205000) stores the Client ID, Client Secret, and Base URL, on a PayPal Settings tab.

2. Customer routing: a Customer Payment Method (AR303010) stores the email address the invoice notification is delivered to.

3. Request out: a user clicks Request PayPal Payment or Send PayPal Request from a Sales Order, an Invoice, or the Payments and Applications screen.

4. Invoice created: the Biz-Tech Services PayPal Acumatica integration calls the PayPal API, emails the invoice to the customer, and writes the PayPal Invoice ID, Invoice URL, and Invoice Number back onto the Acumatica payment.

5. Payment parked: the AR Payment sits on Hold with a PayPal Invoice Status of “Sent” until the provider reports otherwise.

6. Status pulled back: a status check — either the Remove Hold button on a single payment or the Check PayPal Payment Status processing screen in bulk — asks for the current invoice state.

7. Action applied: PAID releases the payment and stores the Transaction ID, PARTIALLY_PAID updates the Paid Amount and leaves the payment on Hold, REFUNDED voids the payment and stores the Refund Number, and CANCELLED deletes the AR Payment record.

8. Monitoring: the processing screen, filtered by PayPal Invoice Status, becomes the daily worklist for everything still awaiting collection.

Step 1: Where PayPal Credentials Enter Acumatica

Configuring the PayPal Payment Method (CA205000)

Nothing can flow until a dedicated Payment Method exists. On the Payment Methods screen (CA205000), click the plus sign to create a record, set the Payment Method ID and Description (for example, ID PAYPAL), and select PayPal in the Means of Payment field. That selection is what makes the new PayPal Settings tab appear — if you do not see the tab, the Means of Payment value is the first thing to check.

On that tab, paste the Client ID and Client Secret from your developer application, enter https://api-m.sandbox.paypal.com/ in Sandbox Base URL for testing and https://api-m.paypal.com/ in Live Base URL for production, and select the Is PayPal Payment checkbox to enable the Biz-Tech Services PayPal Acumatica integration behaviour. One detail matters more than it looks: the system uses the Sandbox URL whenever it is populated and ignores the Live URL, so switching to production means clearing the Sandbox Base URL field. Both fields can stay populated for reference, but a leftover sandbox value will quietly keep you in test mode.

Click Test Connection to confirm the credentials are accepted before you save, then open the Allowed Cash Accounts tab and add the cash or bank account these payments should post to. That cash account is what ties the incoming money to your general ledger, so it is a required part of setup rather than an optional refinement.

Configuring the Customer Payment Method (AR303010)

Each customer who will pay this way needs a Customer Payment Method configured with their PayPal email address, set up on the Customer Payment Methods screen (AR303010) or from the Payment Methods tab of the Customer record. This address is where the invoice notification is delivered, and it is pre-filled automatically on every new payment created for that customer — though it can be edited per payment when a one-off override is required. Customers do not need an account of their own to pay, because PayPal supports guest checkout directly from the emailed invoice.

Step 2: How a PayPal Payment Request Leaves Acumatica

There are three entry points for creating a payment request, and all three end in the same place: an AR Payment record in Acumatica on Hold, and a live PayPal invoice in the customer inbox.

From a Sales Order (SO301000)

This is the most common workflow for businesses collecting payment before or upon shipment. Open the order on the Sales Orders screen (SO301000) and click Create Payment on the PAYMENTS tab; the system reads the order total, currency, and customer details automatically. Add the Cash Account and Payment Reference, and the Request PayPal Payment button appears. Clicking it creates an AR Payment linked to the order, emails the invoice to the customer, stores the PayPal Invoice ID, Invoice URL, and Invoice Number on the payment, and sets the payment on Hold with status “Sent”. The resulting payment stays accessible from the Payments tab of the Sales Order.

From an Invoice (SO303000)

When billing has already been posted — after shipment or service delivery, for example — open the document on the Invoices screen (SO303000) and click Request PayPal Payment. The system creates a payment pre-applied to the invoice, sends it to the customer, and puts the payment on Hold. The invoice amount matches the outstanding balance on the AR invoice, so the two documents cannot drift apart.

From Payments and Applications (AR302000)

Use this route for a standalone payment, such as a deposit not tied to a specific document. On the Payments and Applications screen (AR302000), click the plus sign, select the customer, and choose the PayPal payment method. The PayPal Customer Email field auto-fills from the Customer Payment Method and can be adjusted if needed. Enter the amount and an optional description, optionally apply the payment on the Orders to Apply or Documents to Apply tabs, then click Send PayPal Request in the toolbar. The payment goes on Hold with status “Sent”.

One guardrail applies across all three routes: a payment must not have been sent to PayPal previously before you click Send PayPal Request, and the Payment Method ID field is locked once an invoice has been sent, which prevents accidental changes to a request that is already live with the customer.

Step 3: How PayPal Status Data Returns to Acumatica

This is the direction most teams need to understand clearly. Acumatica polls PayPal on demand — status does not update automatically in the background. A payment will sit at “Sent” indefinitely, even after the customer has paid, until someone triggers a check. There are two ways to trigger one.

Manual Check: The Remove Hold Button

To check a single payment and act on it immediately, open the record on Payments and Applications (AR302000), confirm it is on Hold with status “Sent” or “Partially Paid”, and click Remove Hold in the header toolbar. The Biz-Tech Services Acumatica PayPal integration calls the PayPal API for the latest invoice status and applies the matching action. If the invoice is PAID, the payment is released automatically and a success message appears. If it is PARTIALLY_PAID, a message reports how much has been received and how much remains outstanding, and the payment stays on Hold. If it is CANCELLED, the AR Payment record is deleted. If the invoice is still SENT, the system explains that the payment cannot be released because it has not been paid, and makes no changes.

Bulk Check: The Check PayPal Payment Status Screen

When several payments are outstanding, use the Check PayPal Payment Status processing screen, registered in the Acumatica menu under the Sales Orders Processes module. It gives a centralized view of every AR Payment that has been sent to the provider and is the primary tool for bulk status management. A filter panel at the top narrows the list by PayPal Invoice Status — pick Sent or Partially Paid to isolate one state, or leave it blank to show every linked payment. Select rows and click Process, or click Process All to run every row currently visible in the grid. Each payment is processed in sequence with the same logic as a manual check, and both successes and errors appear in the processing log.

What Each PayPal Status Does to the Acumatica Payment

The AR Payment moves through a lifecycle that mirrors the invoice held by the provider. SENT means the payment sits on Hold with no action taken and the customer has the invoice by email. PARTIALLY_PAID stores the collected amount in the PayPal Paid Amount field while the payment stays on Hold at the original amount. PAID and MARKED_AS_PAID confirm the amount, release the payment, set the status to Paid, and store the Transaction ID. REFUNDED and MARKED_AS_REFUNDED void the payment in Acumatica and store the Refund ID. PARTIALLY_REFUNDED updates the status only — there is no automatic void, and a Credit Memo must be created manually. CANCELLED deletes the AR Payment record from Acumatica.

How Partial Payments Are Tracked in Acumatica

PayPal lets a customer pay less than the full invoice amount in a single transaction, and the invoice stays open so they can return and pay the remainder against the same document — no new invoice is needed. Suppose a $100 invoice is sent from Acumatica and the customer pays $40. The invoice status becomes PARTIALLY_PAID. On the next status check, the PayPal Paid Amount field updates to $40, the PayPal Invoice Status is set to “Partially Paid”, the Acumatica payment amount stays at $100, the payment remains on Hold, and a message reports the amount received and the balance remaining.

The design point behind this matters: Acumatica does not release partial amounts. The payment record always reflects the original agreed amount, and only when the invoice is confirmed fully PAID does the Acumatica payment get released. That is what keeps your accounts receivable accurate rather than showing a half-collected document as settled. Multiple partial payments against the same invoice are supported, and each status check refreshes the Paid Amount. Nothing special is required while you wait — simply re-check the status at a later time.

Cancelling a PayPal Invoice from Acumatica

To pull back a payment request that has been sent but not yet paid, open the AR Payment on AR302000 — it must be in “Sent” status and on Hold, since paid or released payments cannot be cancelled — and click Cancel PayPal Invoice in the toolbar. The Biz-Tech Services Acumatica PayPal connector calls the API to cancel the invoice, the customer is emailed a cancellation notification, and the AR Payment record is deleted from Acumatica. Cancellation is irreversible: if you still want to collect from that customer, a new payment request has to be created from scratch.

How Refunds Flow Back Through Acumatica

For a full refund on a payment already collected and released, open the released AR Payment and click Void Check or Refund — the standard Acumatica actions, enhanced by the Biz-Tech Services Acumatica PayPal integration. The Biz-Tech Services Acumatica PayPal integrator then calls the PayPal API to issue the full refund, voids the payment using the standard Acumatica void workflow, stores the Refund ID on the payment record, and sets the PayPal Invoice Status to “Refunded”. The customer receives a refund notification.

Partial refunds work differently because they originate outside the system. If a partial refund is issued directly in the PayPal portal, the Biz-Tech Services Acumatica PayPal integration detects it on the next status check: the invoice reports PARTIALLY_REFUNDED, Acumatica updates the payment status to “Partially Refunded” and records the Refund ID, but the payment is not voided automatically, because Acumatica does not support partial voids on payment records. You must create a Credit Memo manually for the refunded amount to keep the AR balance accurate. The documented best practice is to issue all refunds from within Acumatica using the Void/Refund button so records stay in sync, and to use the provider portal only when absolutely necessary.

The PayPal Fields Added to Acumatica Records

The Biz-Tech Services PayPal Acumatica integrator adds a set of custom fields to the AR Payment screen, visible when the payment uses a PayPal payment method. Each one is populated at a specific point in the flow, which is useful to know when you are diagnosing a record that looks incomplete. PayPal Invoice ID holds the internal identifier used for API calls and is written after the invoice is created. PayPal Customer Email is populated when the payment method is set, auto-filled from the Customer Payment Method. PayPal Invoice Status appears after Send PayPal Request is clicked. PayPal Invoice Number, the human-readable number the customer sees, is written after the invoice is sent, as is the PayPal Invoice URL used by the Open in PayPal button. Transaction ID and Refund Number are filled once payment or refund is confirmed, and PayPal Paid Amount is maintained while the status is Partially Paid.

These fields are also available on ARAdjust, the applied-to lines, and SOAdjust, the sales order application lines. That is what keeps status information consistent across all related records rather than stranded on the payment header, and it is why you can read the current state from the documents a payment was applied to.

Where to Monitor PayPal Results in Acumatica

Monitoring comes down to a handful of screens and fields. These are the places where the results of the data flow actually surface:

1. Check PayPal Payment Status processing screen — the centralized view of every AR Payment sent to the provider, registered under the Sales Orders Processes module.

2. The PayPal Invoice Status filter on that screen — set it to “Partially Paid” for the recommended daily reconciliation list of invoices awaiting full collection.

3. The processing grid columns: Selected, Payment Ref, Customer, Customer Email, Currency / Amount, Sales Order, Invoice Nbr, PayPal Invoice Nbr, PayPal Status, and Transaction ID.

4. The Payment Ref, Sales Order, and Invoice Nbr columns are clickable, so you can jump straight from the worklist to the underlying Acumatica document.

5. The processing log after Process or Process All — it reports both successes and errors for every row that was checked.

6. PayPal Invoice Status on the AR Payment (AR302000) — Sent, Partially Paid, Paid, Cancelled, Refunded, or Partially Refunded.

7. PayPal Paid Amount on the AR Payment — the cumulative amount actually collected, visible when the status is Partially Paid.

8. Transaction ID on the AR Payment — the payment transaction identifier for paid invoices, or the refund transaction identifier for refunds.

9. Refund Number on the AR Payment — the refund transaction identifier, populated after a refund is processed.

10. PayPal Invoice URL and the Open in PayPal button — the direct link to inspect the invoice in the provider interface when the two systems appear to disagree.

11. The Payments tab of the Sales Order (SO301000) — where the payment created from an order remains accessible.

12. ARAdjust and SOAdjust application lines — status information carried onto applied-to and sales order application records.

PayPal Acumatica Integration: Frequently Asked Questions

Does Acumatica update PayPal payment status automatically?

No. Acumatica polls the provider on demand, so status does not refresh in the background. You must trigger a check either by clicking Remove Hold on an individual payment or by running the Check PayPal Payment Status processing screen. This is by design, and it is the single most important thing to know about how the data flow works.

Why is my PayPal payment status stuck at “Sent” even though the customer paid?

This is almost always the on-demand polling behaviour rather than a fault. Trigger a status check manually with Remove Hold, or run the payment through the processing screen in bulk. If the status still does not move, verify that the invoice is actually marked as PAID inside your PayPal account.

Why does the connection test fail when I save the PayPal Payment Method?

Three causes are documented. The Client ID or Client Secret may be incorrect, so copy them directly from the developer dashboard. The base URL may be wrong — use https://api-m.sandbox.paypal.com for sandbox and https://api-m.paypal.com for live, including the trailing slash. Or the Acumatica server simply cannot reach the endpoint, in which case check firewall and proxy settings for outbound HTTPS on port 443.

What causes the “Customer email not configured” error when sending a request?

The customer does not have a Customer Payment Method set up with a PayPal email address. Open the Customer record, go to the Payment Methods tab, add a row for the PayPal payment method, and enter the email. The request will then send normally, since that address is where the invoice notification is delivered.

Why does PayPal Paid Amount show a value while the payment is still not released?

That is correct behaviour for a PARTIALLY_PAID invoice. Acumatica does not release partial amounts, so the payment stays on Hold at the original amount until the invoice is confirmed fully PAID. The Paid Amount field simply tracks the running total collected so far.

Why does the Refund button return a PayPal error?

Refunds can only be issued for payments that are in a PAID state with the provider, and the invoice must be fully released in Acumatica before a refund can be processed. If the refund was already issued in the PayPal portal, run a status check first to synchronize the record, then work from the updated status.

How do I switch the PayPal Integration from sandbox to production?

Clear the Sandbox Base URL field on the PayPal Settings tab of the Payment Method, or leave it blank. The system uses the Sandbox URL whenever it is populated and ignores the Live URL, so production traffic only begins once the sandbox value is gone. Both fields can be populated at the same time for reference, but live calls are made only with the sandbox field cleared.

Can I cancel a PayPal invoice after the customer has paid it?

No. The payment must be in “Sent” status and on Hold for the Cancel PayPal Invoice button to work, and paid or released payments cannot be cancelled. If money has already been collected, the refund path — Void Check or Refund — is the correct route instead.

Work With the Biz-Tech Services PayPal Integration

Traced end to end, the flow is straightforward: credentials configured once on the Payment Method, a payment request sent from a Sales Order, an Invoice, or Payments and Applications, an AR Payment held at status “Sent”, and a deliberate status check that brings the result back to release, void, or update the record. Knowing where each field is written and which screen to monitor turns PayPal collections into a routine your team runs from one worklist inside Acumatica.

The Biz-Tech Services PayPal Acumatica Connector is built and supported by Biz-Tech Services, Inc. for Acumatica ERP. Visit https://biz-techservices.com to learn more about the Biz-Tech Services PayPal Acumatica integration, licensing requirements, and how to get it configured for your business.

The post How PayPal Payment Data Flows into Acumatica ERP appeared first on Biz-Tech Services.

]]> How CommerceHub Files Flow Through Acumatica ERP https://biz-techservices.com/archives/10351 Fri, 14 Aug 2026 23:51:33 +0000 https://biz-techservices.com/?p=10351 How CommerceHub Files Flow Through Acumatica ERP The CommerceHub Acumatica integration is unusual among connectors, and the difference shapes everything […]

The post How CommerceHub Files Flow Through Acumatica ERP appeared first on Biz-Tech Services.

]]> How CommerceHub Files Flow Through Acumatica ERP

The CommerceHub Acumatica integration is unusual among connectors, and the difference shapes everything about how you troubleshoot it. CommerceHub exchanges data using SFTP, or Secure File Transfer Protocol, rather than direct API requests. Information is not transmitted straight to CommerceHub; it is written into text files that pass through an FTP client such as FileZilla before reaching the CommerceHub platform. Data coming back follows the same route in reverse, travelling from CommerceHub to the file server and only then into Acumatica. Knowing that every record is a file in transit is what makes this Biz-Tech Services Acumatica CommerceHub connector predictable.

The Biz-Tech Services CommerceHub Acumatica Connector adds a dedicated CommerceHub workspace to Acumatica once the customization is published, with a separate screen for each stage of the process. This article follows a record through the full data flow, from the mappings that define connector behavior, through purchase order import and acknowledgement, out to shipment, invoice, and inventory export, and finally to the screens where failures surface. Along the way it identifies the fields that matter and where to check results.

What the CommerceHub Connector for Acumatica Does

CommerceHub is a platform that facilitates e-commerce operations by connecting retailers, brands, and suppliers. The Biz-Tech Services Acumatica CommerceHub Connector for Acumatica ERP links that platform to your back office so that purchase orders placed through CommerceHub arrive as Acumatica sales orders, and so that acknowledgements, shipments, invoices, and inventory quantities flow back out to CommerceHub from Acumatica. Because the exchange is file-based rather than API-based, each of those movements is a file written to or read from an SFTP location rather than a live request and response.

Once the package is published in Acumatica, the CommerceHub workspace becomes available along with its related screens. Each screen is dedicated to one specific process, which is what makes the data flow easy to trace: if you know which stage a record is at, you know which screen to open.

Why CommerceHub Uses Files Instead of an API

Most connectors talk to their platform through direct API interactions. CommerceHub does not, and this is its standout characteristic. Information is written into files and then read for transmission, which introduces an intermediate hop that simply does not exist in API-driven integrations.

The practical consequence is that the file transfer layer is part of your Biz-Tech Services Acumatica CommerceHub integration. When a record does not appear where it should, the cause may be in Acumatica, in CommerceHub, or in the file transfer between them. That third possibility is unique to this Biz-Tech Services Acumatica CommerceHub connector and is worth building into your troubleshooting habits from the start. It also means timing is batch-like rather than instantaneous: records move when files move.

The CommerceHub Data Flow at a Glance

Before looking at individual screens, here is the path records travel through the Biz-Tech Services CommerceHub Acumatica integration:

1. The Mappings screen defines Biz-Tech Services CommerceHub Acumatica connector behavior, including store codes, item cross-references, warehouse and quantity settings, and the inventory template.

2. Import Purchase Orders pulls CommerceHub purchase orders in by store code, creating Acumatica sales orders with a default customer and the real customer address.

3. Two acknowledgement fields on the sales order start as Open, exposing the order on the two acknowledgement export screens until it is processed and both fields turn to Closed.

4. Export CommerceHub Shipment sends out orders that have reached Confirmed Shipment status.

5. Export CommerceHub Invoices sends out orders that have been invoiced, or invoiced and released.

6. Export CommerceHub Inventory synchronizes quantities for the items chosen in the inventory template.

7. Import Failed Purchase Orders and the CommerceHub Errors screen catch anything that did not complete, alongside the Error Log tab on the Mappings screen.

Every field discussed below sits at one of those handoffs.

The Mappings Screen: Where CommerceHub Connector Behavior Is Defined

The Mappings screen is the main configuration screen of the Biz-Tech Services Acumatica CommerceHub integrator. It is used to configure Biz-Tech Services CommerceHub Acumatica integrator settings and define the connector’s behavior, and it is where users set up and manage the various parameters required for the import, export, and synchronization processes. Nearly every question about why the Biz-Tech Services Acumatica CommerceHub connector behaved a certain way is answered somewhere on this screen.

Store codes and per-process configuration

Store codes play a pivotal role in managing distinct configurations and functionalities for specific import and export operations. Each store can be set up individually with its own parameters, including Transaction Type, Description, Default Customer, and Document Type. This is what allows tailored setups per process, so that inventory, item, and shipment operations can each carry their own configuration and accommodate different requirements.

Store code is also the selection field on nearly every processing screen in the Biz-Tech Services CommerceHub Acumatica integrator. Import and export screens filter by it, so choosing the wrong store code is a common reason for a screen to appear empty when records were expected.

Cross-Reference tab: matching CommerceHub item IDs to Acumatica items

The Cross-Reference tab enables the mapping of Acumatica items to their respective item IDs contained within the file during the order import process. Because the incoming file identifies products by CommerceHub’s item ID rather than by your inventory ID, this mapping is what lets an imported order line resolve to the correct Acumatica item. An unmapped item ID is a predictable cause of import failure.

Warehouse Details and the quantity basis for export

On the Warehouse Details tab, the warehouses that need to be exported are added. Alongside them, the Quantity field determines which inventory quantity should be exported to CommerceHub, and there are three available options: On Hand Quantity, Available Quantity, and Available for Shipment Quantity.

This is a decision worth making deliberately rather than accepting a default. On Hand Quantity reports everything physically in the warehouse, Available Quantity accounts for existing commitments, and Available for Shipment Quantity is the most conservative basis. The option you choose directly determines what CommerceHub believes you can sell, so it drives both oversell risk and lost sales.

Inventory Template: choosing which items synchronize

When inventory IDs are selected and saved within the Inventory Template tab, the associated items are displayed on the Export CommerceHub Inventory screen. This functionality is what enables the synchronization of item quantities. In effect the template is the subscription list: an item that is not in the template will not appear for export, no matter what its quantity does.

Error Log and Purge Logs

During the import and export processes for orders, any errors encountered relating to orders are shown and detailed within the Error Log tab, where the messages can be reviewed and resolved. A Purge Logs button enables the deletion of all error messages within the tab at once. Because purging is all-or-nothing, it is worth resolving or recording outstanding messages before using it.

Inbound: Importing CommerceHub Purchase Orders into Acumatica

The Import Purchase Orders screen facilitates the importation of purchase orders from CommerceHub by selecting a preferred store code. After an order is imported, it appears on the Sales Orders screen as a standard Acumatica sales order. Users can either select specific orders and press the Process button to import just those, or use Process All to import every available order at once.

One behavior surprises people the first time they see it, so it is worth explaining before users encounter it. Customers are not imported from CommerceHub. Instead, a default customer is assigned to the sales order. The real customer information is not lost, however: on the Addresses tab of the sales order, the default address information is overridden with the actual customer address received from the imported order. So the order posts against a default customer record while shipping to the genuine end recipient, which is the normal pattern for drop-ship style marketplace fulfillment.

Acknowledgements: The Two Fields That Confirm Receipt

Acknowledgement is the stage that tells CommerceHub you have accepted the order, and Acumatica tracks it with two fields on the Sales Orders screen: Acknowledgement and PO Acknowledgement. The initial status for both fields is Open.

While orders have been generated and their acknowledgements remain at Open status, those orders are visible on both the Export CommerceHub PO Acknowledgment screen and the Export CommerceHub Acknowledgment screen. After the acknowledgements have been processed from both screens, the orders are no longer visible there, and the acknowledgement statuses on the Sales Orders screen transition to Closed.

Two points follow from this that are worth teaching. First, both screens must be processed, not just one, before the order is fully acknowledged. Second, the disappearance of an order from an acknowledgement screen is the expected sign of success rather than a sign that something went missing, and the acknowledgement fields on the sales order are where that success is confirmed.

Outbound: Exporting Shipments to CommerceHub

The Export CommerceHub Shipment screen displays all orders with a Confirmed Shipment status according to the selected store code, and provides the functionality to export those order shipments from Acumatica to CommerceHub. The gating condition is the important part: an order will not appear here until its shipment has actually been confirmed in Acumatica. If a shipment is missing from this screen, the first thing to verify is the shipment status on the order rather than anything in the Biz-Tech Services Acumatica CommerceHub connector.

Outbound: Exporting Invoices to CommerceHub

The Export CommerceHub Invoices screen displays orders that are either invoiced or released when a store code is selected. It offers the capability to export orders that have been invoiced, as well as those that both have an invoice and have already been released. As with shipments, the document state in Acumatica determines visibility on the screen, so the invoice must exist before the export can happen.

Outbound: Exporting Inventory Quantities to CommerceHub

The Export CommerceHub Inventory screen shows the items that were selected and saved in the Inventory Template tab of the Mappings screen, and it is the mechanism that synchronizes item quantities to CommerceHub. The quantity actually sent depends on the Quantity option configured in Warehouse Details, and the warehouses included depend on which ones were added there. Inventory export therefore draws on three separate pieces of configuration at once, which is worth remembering when the exported numbers do not look right.

Handling Failures: Failed Purchase Orders and the CommerceHub Errors Screen

Two screens exist specifically for things that did not go to plan. The Import Failed Purchase Orders screen enables the import of orders that encountered failures during the import process on the Import Purchase Orders screen, and it works the same way, by selecting a store code for the failed orders. This means a failed order is not lost. Once the underlying cause is fixed, commonly a missing item cross-reference, the order can be retried from this screen.

The CommerceHub Errors screen displays all errors received from CommerceHub relating to various processes. Read alongside the Error Log tab on the Mappings screen, which captures errors encountered during Acumatica’s own import and export processing, these two views cover both sides of the exchange. Errors reported by CommerceHub appear on the Errors screen; errors raised while Acumatica processed a file appear in the Error Log.

Where to Monitor CommerceHub Results in Acumatica

When configuring the Biz-Tech Services Acumatica CommerceHub integrator, training users, or investigating a record that has not arrived, these are the fields and screens that reveal what actually happened:

1. Store code on every import and export screen, since each screen filters by it and the wrong selection makes a screen look empty.

2. The Cross-Reference tab on the Mappings screen, which resolves CommerceHub item IDs to Acumatica items during order import.

3. The Quantity option in Warehouse Details, which decides whether On Hand, Available, or Available for Shipment quantity is what CommerceHub sees.

4. The Inventory Template tab, which controls which items appear on the Export CommerceHub Inventory screen at all.

5. The Acknowledgement and PO Acknowledgement fields on the Sales Orders screen, which move from Open to Closed once both acknowledgement screens have been processed.

6. The Addresses tab of an imported sales order, which should carry the real customer address even though the order itself is assigned to the default customer.

7. Shipment status on the order, which governs whether it appears on the Export CommerceHub Shipment screen.

8. Invoice and release status, which govern visibility on the Export CommerceHub Invoices screen.

9. The Error Log tab on the Mappings screen for errors raised during Acumatica processing, remembering that Purge Logs clears every message at once.

10. The CommerceHub Errors screen for errors reported back by CommerceHub itself.

11. The Import Failed Purchase Orders screen, which is where orders that failed to import wait to be retried.

CommerceHub Acumatica Integration: Frequently Asked Questions

What is the CommerceHub connector for Acumatica?

It is a Biz-Tech Services customization that connects the CommerceHub e-commerce platform to Acumatica ERP. Once published, it adds a CommerceHub workspace with dedicated screens for importing purchase orders, exporting acknowledgements, shipments, invoices, and inventory quantities, and reviewing errors. Each screen handles one stage of the process.

Does CommerceHub connect to Acumatica through an API or through files?

Through files. CommerceHub operates using SFTP, or Secure File Transfer Protocol, rather than API requests. Data is not transmitted directly: it is written into text files that pass through an FTP client such as FileZilla before reaching CommerceHub, and data coming back travels the same path in reverse. This file-based approach is the Biz-Tech Services Acumatica CommerceHub connector’s main distinguishing feature compared with the direct API interactions used by other platforms.

Why do imported CommerceHub orders show a default customer?

This is by design. Customers are not imported from CommerceHub, so a default customer is assigned to the sales order instead. The actual customer information still arrives: on the Addresses tab of the sales order, the default address is overridden with the real customer address received from the imported order.

What do the Acknowledgement and PO Acknowledgement fields mean?

They track whether an imported order has been acknowledged back to CommerceHub. Both start at Open, which makes the order visible on the Export CommerceHub PO Acknowledgment and Export CommerceHub Acknowledgment screens. Once the acknowledgements have been processed from both screens, the order disappears from them and both fields change to Closed.

Which inventory quantity is exported to CommerceHub?

Whichever one you select in the Quantity field of Warehouse Details. The three options are On Hand Quantity, Available Quantity, and Available for Shipment Quantity. Only the warehouses added on that screen are exported, and only the items saved in the Inventory Template tab appear on the Export CommerceHub Inventory screen.

What happens when a CommerceHub purchase order fails to import?

It is not lost. The Import Failed Purchase Orders screen allows orders that encountered failures during import to be brought in, by selecting the store code for those failed orders. Check the Error Log tab on the Mappings screen for the reason first, resolve it, then retry the import from the failed orders screen.

Why is an order missing from an export screen?

Each export screen filters on both a store code and a document state. Confirm the correct store code is selected, then check the order’s status: shipments appear on the Export CommerceHub Shipment screen only once the shipment is confirmed, and orders appear on the Export CommerceHub Invoices screen only once they are invoiced or invoiced and released. For acknowledgements, an order disappearing is the expected result of successful processing.

Work With the Biz-Tech Services CommerceHub Connector

The Biz-Tech Services CommerceHub Acumatica integration becomes straightforward once you think in files. The Mappings screen defines how the Biz-Tech Services CommerceHub Acumatica connector behaves, store codes separate one process from another, purchase orders arrive as sales orders under a default customer with the real shipping address, acknowledgements close the loop back to CommerceHub, and shipments, invoices, and inventory quantities flow outward as their supporting documents reach the right state. When something does not arrive, the Error Log, the CommerceHub Errors screen, and the Import Failed Purchase Orders screen tell you where it stopped.

If your business sells through CommerceHub and wants orders, acknowledgements, shipments, invoices, and inventory synchronized with Acumatica without manual re-keying, we are glad to help you scope, configure, and roll out the Biz-Tech Services Acumatica CommerceHub integration. Visit https://biz-techservices.com to learn more about our Acumatica integration expertise or to schedule a personalized demonstration of the Biz-Tech Services Acumatica CommerceHub Connector.

The post How CommerceHub Files Flow Through Acumatica ERP appeared first on Biz-Tech Services.

]]> How DSCO Data Flows Through Acumatica Order-to-Cash Automation https://biz-techservices.com/archives/10338 Fri, 14 Aug 2026 05:42:55 +0000 https://biz-techservices.com/?p=10338 How DSCO Data Flows Through Acumatica Order-to-Cash Automation The DSCO data flow in Acumatica moves a retailer order through five […]

The post How DSCO Data Flows Through Acumatica Order-to-Cash Automation appeared first on Biz-Tech Services.

]]> How DSCO Data Flows Through Acumatica Order-to-Cash Automation

The DSCO data flow in Acumatica moves a retailer order through five documented stages: DSCO orders are pulled into Acumatica ERP and turned into sales orders or invoices, the purchase order is acknowledged back to DSCO, inventory quantities are pushed out, shipment confirmation and tracking numbers are exported when the invoice is prepared, and the invoice is exported when it is released, which moves the order to Shipped. Each stage is a separate screen in Acumatica, and each one writes a status value you can read back on the order.

That separation matters more than it first appears. Because every leg of the flow is its own processing screen with its own selection grid, your business can see exactly where a record is sitting at any moment, and a failure in one leg does not silently poison the rest. This article walks the whole path in sequence, from installing the customization package and testing credentials through to exporting invoices and cancellations, and names the screens, tabs, checkboxes and fields that control each hop. Where the product documentation is silent on a step, this article says so rather than guessing.

What the DSCO Connector for Acumatica Does

The Biz-Tech Services DSCO Acumatica Connector is a customization package for Acumatica Enterprise Resource Planning (ERP) that connects an Acumatica instance to a DSCO store. DSCO is a drop-ship and retailer-supplier network, so the connector sits between the retailer-facing platform and the supplier-side Acumatica system that actually picks, ships and bills the goods.

Communication runs over the DSCO API. The Bzi-Tech Services Acumatica DSCO connector authenticates with an Access Token and a Base URL that you store on the DSCO Store screen in Acumatica, and every subsequent action – retrieving orders, acknowledging them, updating quantities, setting tracking numbers, sending invoice numbers, canceling orders and canceling individual lines – is an API request issued from a specific Acumatica screen.

The product must be installed on an Acumatica system carrying one of the specified licenses: PCSR, PERP or SAAS. If your instance is on a different license type, confirm eligibility with Biz-Tech Services before planning an implementation, because this is a prerequisite rather than a configuration option.

It is worth being precise about scope. The Bzi-Tech Services Acumatica DSCO connector automates the DSCO-facing legs of the order-to-cash cycle – order intake, acknowledgment, inventory availability, shipment confirmation and invoice export. The documentation does not describe payment application or cash receipt handling; the connector’s documented responsibility ends when the invoice number has been sent to DSCO and the order reaches Shipped.

The DSCO Data Flow at a Glance

Before looking at individual screens, it helps to see the whole path in order. Each of the following steps corresponds to a real screen or button in Acumatica, and each one hands a record to the next step:

1. Install the DSCO Connector customization package on the Customization Projects form (SM204505) and publish it to the tenant.

2. Configure the DSCO Store screen: enter the Partner Code, Access Token and Base URL, then use Test Credentials to confirm the connection works before anything is imported.

3. Map the supporting data – default Customer, warehouse cross-references, inventory item cross-references and cancel codes – on the DSCO Store tabs, so imported records can resolve to real Acumatica records.

4. Pull orders inbound on the Import DSCO Orders screen using GET ORDERS, then IMPORT or IMPORT ALL to create sales orders or invoices in Acumatica.

5. Acknowledge the purchase order back to DSCO, either automatically through the Set Order as Acknowledged checkbox on the store, or manually from the Export DSCO PO Acknowledgment screen.

6. Push inventory availability outbound from the Export DSCO Inventory Quantities screen so DSCO sees current quantities for the mapped items and warehouses.

7. Confirm the shipment outbound on the Export DSCO Shipments screen, which sets the tracking number on the order and moves it to Pending Shipment.

8. Export the invoice on the Export DSCO Invoices screen, which sets the invoice number in DSCO and moves the order to Shipped, with the invoice status set to Closed.

Setting Up the DSCO Connector in Acumatica

How do you install the DSCO Connector package?

The Biz-Tech Services Acumatica DSCO connector is delivered as a deployment package and installed through the standard Acumatica Customization Projects form, form ID SM204505. This is the same form your business already uses to add a customization project, open a project in the Customization Project Editor, validate one or several projects, publish projects to one or more tenants, cancel a publication, view the published project XML, export a project as a deployment package, import a project from an existing package, and delete a project.

The relevant operation here is import followed by publish. When you upload the package, the platform uploads the selected package, creates the corresponding customization project, and saves the project in the database. Publishing that project is what makes the DSCO screens appear in your Acumatica instance. Because the Bzi-Tech Services DSCO Acumatica connector arrives through the ordinary customization pipeline, it is also validated and republished the ordinary way after an Acumatica upgrade.

What goes on the General Settings tab of the DSCO Store screen?

The DSCO Store screen is the control panel for the entire Bzi-Tech Services Acumatica DSCO integration. Once the connection has been established, you use this form to specify the store settings, select the entities that need to be synchronized, define the default settings for customer synchronization, inventory items and order synchronization, and map shipping rules between Acumatica ERP and the store.

On the General Settings tab, Partner Code is a lookup field that indicates the corresponding DSCO store, and Description is a free-text field used to describe that store. These two fields identify which trading relationship the record belongs to, which matters as soon as your business runs more than one store.

Two credential fields drive the API connection. Access Token is a digital credential used to authorize and authenticate a user or application, granting specific permissions to access resources or perform actions within a system or service. Base URL is the fundamental web address, or Uniform Resource Locator, that serves as the starting point for all relative URLs within a website or web application – in other words, the root endpoint that every API call is built on top of.

Why should you use Test Credentials before importing anything?

Test Credentials is a button that allows you to test the ability to connect to the DSCO store via the API by using the information specified on the General Settings tab. Running it is not a formality. Every downstream screen in the flow – order import, acknowledgment, inventory sync, shipment export, invoice export, cancellation export – depends on this one connection. If the Access Token or Base URL is wrong, each of those screens will fail individually and the failures will look like separate problems. Testing the credentials once, at setup time, turns a scattered set of symptoms into a single answer.

Order Settings: How DSCO Orders Enter Acumatica

The Order Settings tab of the DSCO Store screen decides what an imported order actually becomes in Acumatica and which orders are eligible to come in at all. These settings are read at import time, so changing them changes the behaviour of every subsequent import.

What document type do DSCO orders become in Acumatica?

The Import DSCO Orders To field specifies the document type into which the orders will be imported. A DSCO order can be imported to Acumatica as a Sales Order or as an SO Invoice. This is a structural decision rather than a cosmetic one: importing as a sales order gives your business the full pick, pack, ship and invoice sequence, while importing directly as an SO invoice shortens the path. Choose based on whether shipments are actually processed inside Acumatica.

Order Type sets the default type of orders to be created by the Bzi-Tech Services DSCO Acumatica integration. Together with the document type, it determines which Acumatica order processing rules apply to everything DSCO sends you, so it is worth aligning with how your business already segments drop-ship volume from ordinary sales.

What does the DSCO Status setting control?

DSCO Status is the status of the corresponding order that will be imported to Acumatica, presented as a set of checkboxes. The documentation is explicit on this point: the corresponding order status checkbox must be selected for the order to be retrieved and imported. If an expected order never appears in the import grid, this is the first setting to check, because an unchecked status silently filters the order out at the source rather than reporting an error.

When should Set Order as Acknowledged be checked?

When the Set Order as Acknowledged checkbox is selected, sending back a separate acknowledgment for the order is unnecessary – the Bzi-Tech Services Acumatica DCO integrator treats the order as acknowledged as part of the import. With the checkbox enabled and the order imported with the corresponding settings, the Acknowledged Status in DSCO field on the Sales Orders screen is set to Closed.

If the checkbox is not selected in a store, acknowledgment becomes a deliberate manual step: you send the acknowledgment for the corresponding order from the Export DSCO PO Acknowledgment screen in Acumatica. Neither approach is inherently better. Leaving the checkbox clear gives your business a review gate before the retailer is told the order is accepted; selecting it removes a step for high-volume, low-touch drop-ship traffic.

How do Begin Order Date and Last Imported Order Date limit what is retrieved?

Begin Order Date allows you to filter data retrieval, and Last Imported Order Date records the date when the last order was imported. The pair works as a window on the retailer side of the conversation. Begin Order Date is particularly important on a new installation, because without it a first retrieval can reach back further than your business intends and pull historical orders that were already handled elsewhere.

What do the two export checkboxes on Order Settings do?

Two checkboxes on the Order Settings tab wire the outbound half of the order-to-cash flow to ordinary Acumatica document processing, and they are the most consequential settings on the screen.

1. Export Shipment During Prepare Invoice: if this checkbox is selected, the system sends shipment information to DSCO and marks the order as shipment pending. If it is not selected, no API request is sent and no update is made in the Bzi-Tech Services Acumatica DSCO connector.

2. Export Invoice During Release Invoice: if this checkbox is selected, the system sends invoice information to DSCO and the order gets the Shipped status.

The design intent is that shipment confirmation and invoice transmission ride along with the Acumatica actions your team already performs. Preparing the invoice is what tells DSCO the goods are going out; releasing the invoice is what tells it the transaction is billed. If either checkbox is clear, the corresponding export screen stays empty and the DSCO order status never advances, which is the single most common reason an Bzi-Tech Services Acumatica DSCO integration appears to have stopped working.

Mapping Customers, Warehouses and Items Before the First Import

An incoming order arrives with the retailer’s own identifiers. Before it can become an Acumatica document, those identifiers have to resolve to real Acumatica records – a customer, a warehouse, an inventory ID. The DSCO Store screen provides a dedicated tab for each of these mappings, and skipping them is the most reliable way to make imports fail.

What does the Customer Information tab set?

The Customer field on this tab allows you to select a default customer, which is then set on DSCO orders during the import process. Because drop-ship traffic from a single retailer partner typically bills to one account, a default customer keeps the import from needing to resolve a customer per order.

The Cross-Reference options on the same tab allow you to select the entities that should be matched in DSCO and Acumatica during the transition. This is a gate as well as a selection: only the checked entities of Cross-Reference Options will show up in the drop-down field on the Cross-Reference tab. If an entity you expect to map is missing from that drop-down, the cause is almost always an unchecked box here.

Why does the Use Cross Ref for Warehouse checkbox matter?

If the Use Cross Ref for Warehouse checkbox is selected, the values of the DSCO item’s warehouse must be mapped to Acumatica warehouse values from the Cross-Reference tab. The documentation carries an explicit warning about the consequence of skipping this: if the warehouse values are not mapped, the order import process produces the error message “Warehouse does not have value.”

That error is worth memorizing, because it is a configuration failure dressed up as a data failure. Nothing is wrong with the order itself; the Bzi-Tech Services DSCO Acumatica connector simply has no Acumatica warehouse to put the line against.

What is the Cross-Reference tab for?

The Cross-Reference tab holds the mappings that let the Bzi-Tech Services DSCO Acumatica integrator translate data elements between the Acumatica system and the DSCO system. The documentation is emphatic that setup accuracy here is a prerequisite for the outbound half of the flow as well as the inbound half: it is important to ensure the setup is correct before sending an API request to update order status and set tracking numbers in DSCO, and the accuracy of the data on this tab is crucial to the success of that request. If the mapping is incorrect or incomplete, the result is a failure to update order status and set tracking numbers correctly.

In practice this means a broken cross-reference does not only block imports. It can also let an order in and then break shipment confirmation days later, at the point where the retailer is waiting for a tracking number.

How does the Inventory Items tab map DSCO items to Acumatica inventory IDs?

The drop-down fields in the cross-reference section of the Inventory Item tab let you choose how to search for the item within the Bzi-Tech Services Acumatica DSCO connector and map it to the Acumatica Inventory ID. In the documented example, the drop-down value is set to SKU, meaning Stock Keeping Unit. With that setting, the system searches for an item with the corresponding SKU number and then associates it with the Acumatica inventory ID.

The same warning applies as with warehouses: if the item values are not mapped, an error message appears during the order import process. Choosing the matching key is therefore a decision about which identifier your business can guarantee is identical on both sides, not just a preference.

What goes on the Inventory Availability tab?

On the Inventory Availability screen you add the warehouses that need to be in sync with DSCO. Two behaviours follow from that list. First, if warehouses are selected on this screen, the exported item quantity displays the sum of quantities from those selected warehouses. Second, the item quantity synced from Acumatica to DSCO depends on the chosen drop-down value: On Hand, Available, or Available for Shipment.

That drop-down deserves a real decision rather than a default. On Hand reports physical stock regardless of commitments; Available and Available for Shipment reflect narrower, more conservative numbers. For drop-ship traffic, over-reporting availability to a retail partner produces oversell and cancellations downstream, which is precisely the failure the cancellation screens later in this article exist to clean up.

What are Cancel Codes used for?

Order cancel reasons are added to the Cancel Codes tab. When canceling orders, a cancellation reason must be selected, and the values offered are the reason codes that have already been set up on this tab. The list of cancellation reasons can be imported or exported as an Excel file, which makes it practical to keep the code list aligned with whatever the retailer partner expects without retyping it.

Setting these up early is a small task with an outsized payoff. Because a cancel code is mandatory at cancellation time, an empty Cancel Codes tab blocks a cancellation at exactly the moment your business is under time pressure to send it.

Inbound: Importing DSCO Orders into Acumatica

With the store configured, the inbound leg runs from the Import DSCO Orders screen. This screen allows you to get and import all orders from DSCO into Acumatica, and it splits the work into two deliberately separate actions – retrieval and import.

What does the GET ORDERS button do?

Pressing the GET ORDERS button retrieves the orders from DSCO. After clicking the button, a timer indicates the elapsed time until the process is complete. The documentation flags an important behaviour here: after clicking GET ORDERS, the screen gets and displays at once all orders for the selected period. On a first run, or after a long gap, that can be a large set, which is why Begin Order Date on the store settings is worth configuring deliberately.

Retrieval is not the same as import. At this stage the orders are staged on the screen for review, and nothing has been created in Acumatica yet. You can click an Order Number to view the corresponding order in a pop-up window, with the most important information shown on the DSCO Orders screen.

How do you import selected DSCO orders?

By selecting the order or orders that need to be imported and clicking the IMPORT button, you begin the import process. Alternatively, you can click the IMPORT ALL button to import every order in the grid. After pressing IMPORT, the selected orders get filtered off the screen – which doubles as your progress indicator, since what remains in the grid is what has not yet been imported.

A long-running import is not a trap. Users can cancel the process of importing orders by clicking Cancel Processing, so a batch that was started against the wrong selection can be stopped rather than waited out.

What happens when an order fails to import?

If an error occurs while processing, an error message is displayed in the line corresponding to that order in the grid. Users can hover the cursor over the red cross to view additional information about the error. For deeper diagnosis, the documentation directs you to click TOOLS then Trace to access additional information about an error.

This per-line error model is why import is worth running in reviewable batches. A failure is attributed to the specific order that caused it, the rest of the batch is unaffected, and the failed order stays visible in the grid so it can be retried after the underlying mapping is corrected.

What does the DSCO Orders screen show after import?

This screen is the record of what the Bzi-Tech Services Acumatica DSCO integrator knows about each order. Its DSCO Order Status section initially displays the status held in DSCO. Once the order is marked as shipped there, you can update that status inside Acumatica by opening the Actions menu and clicking the Refresh Order button – a manual pull that reconciles Acumatica’s copy of the status with the DSCO platform.

After an order has been imported and an invoice created, this screen also shows the sales order number and the invoice number associated with that order. That makes DSCO Orders the natural place to answer the question “what did this order actually become in Acumatica?” without hunting through the Sales Orders screen.

Acknowledging DSCO Purchase Orders

Acknowledgment is the first thing the retailer hears back after sending an order, and it is controlled entirely by the Set Order as Acknowledged checkbox described earlier.

If that checkbox is not selected on the store, then after importing an order into Acumatica it appears on the Export DSCO PO Acknowledgment screen, which gives you the opportunity to send the acknowledgment from there. After sending the acknowledgment for the corresponding order from that page, the order disappears from the screen, and the Acknowledged Status in DSCO field on the Sales Orders screen is updated to Closed.

The disappear-when-done pattern repeats across every outbound screen in this Bzi-Tech Services Acumatica DSCO connector, and it is the most useful monitoring habit to build. Each export screen is effectively a work queue: if a document is still listed, the corresponding message has not reached DSCO yet.

Keeping DSCO Inventory Quantities in Sync

The Export DSCO Inventory Quantities screen is used for syncing Acumatica and DSCO inventory quantities. Beforehand, you choose the required items from the Inventory Items tab of the DSCO Store screen and press Save, which is what puts those items in scope for the sync.

There are two documented ways to update an inventory quantity from this screen:

1. Select the checkbox for the item and click the SYNC button. The Quantity field is pushed to DSCO and the inventory quantity there is updated. Quantity is a read-only field that indicates the inventory quantity of the item in the Acumatica system.

2. Change the DSCO Quantity field, select the checkbox, then click SYNC. The inventory quantity in DSCO is updated based on the DSCO Quantity value rather than the Acumatica figure.

The second option exists for good reason. There are legitimate cases where the number a retailer should see is not the raw Acumatica figure – stock reserved for another channel, for example – and the editable DSCO Quantity field lets your business publish a deliberate number. Because Quantity is read-only, the two paths cannot be confused: whatever you type goes in DSCO Quantity, and whatever Acumatica calculates stays in Quantity.

Outbound: Confirming Shipments Back to DSCO

Shipment confirmation is where the order-to-cash flow turns outbound, and it is the leg the retailer is usually watching most closely.

When the relevant checkbox – Export Shipment During Prepare Invoice – is chosen within the store, the Export DSCO Shipments screen presents the count of shipments that have been confirmed. Upon selecting and processing these shipments, the order status in the Bzi-Tech Services DSCO Acumatica integrator is updated to Pending Shipment, and the tracking number is set on the DSCO order.

Two behaviours are worth holding onto. First, if the Export Shipment During Prepare Invoice checkbox is not selected, no API request is sent and no updates are made by the Bzi-Tech Services Acumatica DSCO integrator – the screen simply has nothing to do. Second, once the shipment is dispatched, the Shipment Status in DSCO field shows the value Closed and the shipment number no longer appears on the Export DSCO Shipments screen.

That second point is the practical monitoring rule for this stage. A shipment number that is still sitting on the Export DSCO Shipments screen has not been confirmed, no matter what the Acumatica shipment itself says.

Outbound: Exporting Invoices to Close the DSCO Order

The invoice is the last documented outbound message in the flow, and it is what moves the DSCO order to its final state.

If the Export Invoice During Release Invoice checkbox is chosen in the store settings, processing invoices from the Export DSCO Invoices screen updates the DSCO order status to Shipped and sets the corresponding invoice number there. The invoice status in DSCO is then set to Closed, and the invoice number is removed from the Export DSCO Invoices screen.

This is the endpoint of the connector’s documented responsibility. From the retailer’s side of the network, the order is now shipped, carries a tracking number and carries an invoice number; from your side, the Acumatica invoice is released and enters your normal accounts receivable process. The product documentation does not describe payment application, cash receipts or remittance handling, so anything beyond the released invoice sits outside what the Bzi-Tech Services DSCO Acumatica connector is documented to do.

Cancellations: Exporting Canceled DSCO Orders and Line Items

Not every order completes, and the Bzi-Tech Services Acumatica DSCO connector treats a cancellation as an outbound message that has to reach DSCO explicitly. Two screens handle it, one for whole orders and one for individual lines.

How do you cancel a whole DSCO order?

The Export DSCO Canceled Orders screen allows you to export all orders that have been canceled from the Sales Orders screen. To cancel a DSCO order from the Sales Orders screen, open Actions and select the Cancel Order button. A pop-up window appears where you fill in the Canceling a Line and DSCO Cancel Code fields – the latter offering the reason codes already set up on the Cancel Codes tab of the DSCO Store screen. After pressing Yes, the order is canceled and appears on the Export DSCO Canceled Orders screen. Upon selecting the order and processing it, the system sends an API request to update the order status to Canceled in DSCO.

How do you cancel a single line on a DSCO order?

The Export DSCO Order Item Canceled screen allows you to cancel the line item of a DSCO order while the order is on the Sales Orders screen. For item cancellation you can change the quantity to zero or delete the line, after which a pop-up window appears where you fill in the Canceling a Line and DSCO Cancel Code fields. After pressing Yes, the cancellation is recorded and appears on the Export DSCO Order Item Canceled screen. Upon selecting the order and processing it, the system sends an API request to update the item status to Canceled in DSCO.

The important discipline here is that canceling in Acumatica is only half the transaction. Until the record is selected and processed on the matching export screen, DSCO still believes the order or the line is live, and the retailer is still expecting it.

Where to Monitor DSCO Results in Acumatica

Because each leg of the flow has its own screen and its own status field, monitoring the Bzi-Tech Services DSCO Acumatica integration is a matter of knowing which field answers which question. These are the exact places to look:

1. DSCO Store, General Settings tab – use Test Credentials to confirm the Access Token and Base URL still authenticate against the API.

2. DSCO Store, Order Settings tab – check Last Imported Order Date to see when the last successful order import ran, and Begin Order Date to see how far back retrieval reaches.

3. DSCO Store, Order Settings tab – confirm the DSCO Status checkboxes, since an unchecked status prevents matching orders from being retrieved at all.

4. Import DSCO Orders screen – anything still listed in the grid after a GET ORDERS run has been retrieved but not yet imported.

5. Import DSCO Orders screen – hover over the red cross on a grid line to read the error message for that specific order, then use TOOLS then Trace for the fuller detail.

6. DSCO Orders screen, DSCO Order Status section – the current DSCO-side status of the order, refreshable through Actions then Refresh Order.

7. DSCO Orders screen – the sales order number and invoice number created in Acumatica for that order.

8. Sales Orders screen, Acknowledged Status in DSCO field – Closed means the purchase order acknowledgment has been sent.

9. Export DSCO PO Acknowledgment screen – any order still listed has not been acknowledged yet.

10. Export DSCO Shipments screen and the Shipment Status in DSCO field – a shipment number that has disappeared from the screen and shows Closed has been confirmed with its tracking number.

11. Export DSCO Invoices screen – an invoice number that has been removed from the screen has been sent, with the order moved to Shipped and the invoice status in DSCO set to Closed.

12. Export DSCO Canceled Orders and Export DSCO Order Item Canceled screens – anything still listed is a cancellation that has not been sent.

DSCO Acumatica Integration: Frequently Asked Questions

Why is a DSCO order not importing into Acumatica?

Work through the settings in the order the Bzi-Tech Services DSCO Acumatica connector reads them. First confirm the corresponding order status checkbox is selected under DSCO Status on the Order Settings tab, because the documentation states the order will not be retrieved and imported otherwise. Then check Begin Order Date, which filters data retrieval and can exclude older orders entirely. If the order is retrieved but fails at import, hover over the red cross on its line in the Import DSCO Orders grid and use TOOLS then Trace for the detail.

What does the error “Warehouse does not have value” mean?

This error appears during the order import process when the DSCO item’s warehouse values have not been mapped to Acumatica warehouse values. It occurs when the Use Cross Ref for Warehouse checkbox is selected on the Customer Information tab but the corresponding mapping is missing from the Cross-Reference tab. Add the warehouse mapping on the Cross-Reference tab and import the order again – nothing needs to change on the DSCO side.

Why did DSCO shipment confirmation fail or never happen?

The first thing to check is the Export Shipment During Prepare Invoice checkbox on the Order Settings tab of the store; if it is not selected, no API request is sent and no updates are made in the Bzi-Tech Services Acumatica DSCO integrator at all. If the checkbox is selected and the shipment is still listed on the Export DSCO Shipments screen, the shipment has not been selected and processed yet. If processing is failing, review the Cross-Reference tab, since the documentation states that incorrect or incomplete mapping there causes failures to update order status and set tracking numbers.

Can a DSCO order be imported as an invoice instead of a sales order?

Yes. The Import DSCO Orders To field on the Order Settings tab specifies the document type into which DSCO orders will be imported, and the documented options are Sales Order and SO Invoice. Choose SO Invoice when your business does not process the shipment inside Acumatica, and Sales Order when you need the full order, shipment and invoice sequence – including the shipment confirmation leg back to DSCO.

How do I send a purchase order acknowledgment to DSCO manually?

Leave the Set Order as Acknowledged checkbox clear on the DSCO Store. Imported orders then appear on the Export DSCO PO Acknowledgment screen, where you select and send the acknowledgment. Once sent, the order disappears from that screen and the Acknowledged Status in DSCO field on the Sales Orders screen changes to Closed.

Which quantity does Acumatica send to DSCO?

It depends on two settings on the Inventory Availability tab. The warehouses you add there determine the scope, and if warehouses are selected the exported item quantity is the sum of the quantities from those warehouses. The drop-down value then determines the basis: On Hand, Available, or Available for Shipment. You can also override the figure at send time by editing the DSCO Quantity field on the Export DSCO Inventory Quantities screen before clicking SYNC.

Why is a canceled Acumatica order still open in DSCO?

Canceling the order on the Acumatica Sales Orders screen through Actions then Cancel Order only stages the cancellation. The order then appears on the Export DSCO Canceled Orders screen, and the API request that updates the order status to Canceled in DSCO is sent only when you select that record and process it. The same two-step pattern applies to line-level cancellations on the Export DSCO Order Item Canceled screen.

How do I update a DSCO order status inside Acumatica after it ships?

Open the DSCO Orders screen for that order, open the Actions menu and click Refresh Order. The DSCO Order Status section initially shows the status captured at import time; Refresh Order pulls the current status from DSCO once the order has been marked as shipped there, so Acumatica reflects reality rather than a stale value.

Work With the Biz-Tech Services DSCO Connector

The DSCO data flow through Acumatica is a sequence of clearly separated hops: configure and test the connection on the DSCO Store screen, map customers, warehouses, items and cancel codes so incoming identifiers resolve to Acumatica records, import orders on the Import DSCO Orders screen, acknowledge them, keep inventory quantities current, then let the Export Shipment During Prepare Invoice and Export Invoice During Release Invoice checkboxes carry shipment confirmation and invoice numbers back out as your team prepares and releases invoices in the normal way. Every stage leaves a status you can read, and every outbound screen behaves as a queue that empties when the message has landed. Getting the cross-reference mapping right up front is what keeps that queue moving.

The DSCO Connector for Acumatica ERP is built and supported by Biz-Tech Services, Inc. If your business is planning a Bzi-Tech Services Acumatica DSCO integration, or wants a review of an existing configuration, visit https://biz-techservices.com to learn more about the connector and the rest of the Biz-Tech Services product range for Acumatica.

The post How DSCO Data Flows Through Acumatica Order-to-Cash Automation appeared first on Biz-Tech Services.

]]> How ShipStation Data Flows Between Shipping and Acumatica ERP https://biz-techservices.com/archives/10330 Wed, 12 Aug 2026 04:30:12 +0000 https://biz-techservices.com/?p=10330 How ShipStation Data Flows Between Shipping and Acumatica ERP ShipStation data moves through Acumatica ERP as a round trip: a […]

The post How ShipStation Data Flows Between Shipping and Acumatica ERP appeared first on Biz-Tech Services.

]]> How ShipStation Data Flows Between Shipping and Acumatica ERP

ShipStation data moves through Acumatica ERP as a round trip: a sales order is exported to a connected store on the shipping platform, the label and shipment are produced there, and the shipment number and tracking number come back to update the order and move it to Prepare Invoice. The Biz-Tech Services ShipStation Acumatica Connector is what carries records across that loop. It adds a store record to Acumatica, a set of processing screens for pushing orders out and pulling shipments back, and dedicated fields on the Sales Orders and Shipments screens so users can see exactly what happened to each document.

The Biz-Tech Services Acumatica ShipStation connector is not a one-directional feed. It supports two integration directions, and the direction you choose changes which tabs appear on the store record, which processing screens become usable, and which way orders, shipments, customers, and items travel. This article follows the records themselves rather than the chapter order of the documentation: first the credentials and store setup that make any transfer possible, then orders moving out for fulfillment, then shipment and tracking data coming back, then the alternative flow driven by the Confirm Shipment process, then the reverse direction where the shipping platform is the system of record for the order, then item synchronization, and finally where to look when something does not arrive.

What the ShipStation Connector for Acumatica Does

ShipStation is a web-based shipping solution built to optimize order fulfillment for online businesses. It consolidates orders from more than 70 ecommerce channels, generates shipping labels, packing slips, and pick lists in batch mode, communicates tracking information to customers, and provides automation, filtering and viewing options, wireless printing, and a dedicated mobile app. The Biz-Tech Services Shipstation Acumatica connector links that platform to Acumatica ERP so that fulfillment and shipping run as one connected process instead of two separate systems that someone has to reconcile by hand.

In practical terms it does two things. First, order syncing: orders move between the two systems so that documents originating in diverse sales channels can be viewed and managed centrally in the shipping interface. Second, shipping and fulfillment: users generate labels, produce packing slips, and manage shipments directly in that interface, using the carrier options and shipping methods available there, and the result is written back against the correct order in the ERP. The Biz-Tech ShipStation product must be installed on a system carrying one of the specified licenses: PCSR, PERP, or SAAS.

The ShipStation Data Flow at a Glance

Before looking at individual screens, it helps to see the whole round trip in order. The sequence below describes the primary Acumatica to ShipStation direction, where the sales order starts in the ERP and the shipment is created on the shipping side:

  • Setup: the package is published on the Customization Projects (SM204505) form, and a ShipStation Store record is created with Connection Settings holding the Consumer Key, Consumer Secret, and Base URL that authenticate every call.
  • Direction: the Integration Option on the store record is set to Acumatica to ShipStation, and the Process Flow is set to Shipment in ShipStation, which enables the export and import processing screens for this path.
  • Reference data: the Get Stores, Get Carriers, and Get Packages buttons, plus the ShipStation Warehouses tab, pull connected stores, carrier codes, package types, and warehouses into Acumatica so exported orders carry values the shipping platform recognizes.
  • Orders out: a sales order is exported from the Create Orders in ShipStation screen, or from the Actions menu of the Sales Orders screen, and the order is created under the configured Store Code and ShipStation Store ID.
  • Acknowledgement: the platform returns an identifier that is written into the ShipStation Order ID field on the Sales Orders screen. That field is the proof the order left Acumatica.
  • Fulfillment: warehouse staff work the order on the shipping side, choose the carrier and service, and generate the label. Acumatica takes no part in this stage.
  • Shipment and tracking back in: the Import Shipment from ShipStation screen, or the Get Shipstation Shipments action on the Sales Orders screen, pulls the shipment across and adds the shipment number and tracking number to the corresponding order.
  • Handover to billing: once that information lands, the order status is updated to Prepare Invoice, so the record continues through the standard order-to-invoice process.

Setup and Credentials: What Has to Exist Before Any Data Moves

Nothing crosses between the two systems until the package is published and a store record exists. This stage is worth doing carefully, because almost every failure users report later traces back to a setting chosen here.

Installing the package

The package is installed through the Customization Projects (SM204505) form. This is the standard form used to add a new customization project, open a project for editing in the Customization Project Editor, validate one or more projects, publish a project for one or multiple tenants, cancel a publication, view the XML of a published project, export a project as a deployment package, import a project from an existing deployment package, and delete a project. On import, the platform uploads the selected package, creates the corresponding customization project, and saves that project in the database. Publishing it is what makes the new Acumatica screens and fields appear.

Connection Settings: the credentials behind every transfer

The ShipStation Store screen is where all configuration lives, including Connection Settings, the Integration Option, and the setup relevant to the selected integration. The Store Code field is a lookup field that corresponds to the specific store, which ensures the right one is selected for the integration, and the Description field holds a short description of it.

Connection Settings is where users enter the Consumer Key, Consumer Secret, and Base URL credentials. These three values establish the link between the two platforms and are used to authenticate and enable communication between them. Because every subsequent button on every screen depends on them, they are the single highest-value thing to verify. That is what the Test Credentials button is for: it verifies the ability to connect through the Application Programming Interface, or API, using the information supplied on the Connection Settings tab. If a value has to change later, the Edit Credentials option lets users modify what is stored.

Integration Option: the setting that decides which way records travel

The Integration Option defines the direction of the data flow. Users choose whether the integration runs from ShipStation to Acumatica or from Acumatica to ShipStation. This is not a cosmetic preference. It determines which tabs the store record displays and which processing screens will accept the store code at all, so setting it incorrectly makes entire screens refuse to work.

Configured as ShipStation to Acumatica, the system allows orders to be imported with or without their shipments, and the store record shows the General Info, Import Info, Ship Via Cross Reference, Warehouse Cross Reference, and Inventory Details tabs. Configured as Acumatica to ShipStation, the visible tabs are General Info, Carriers and Services, Packages, and ShipStation Warehouses. The General Info tab stays consistent and unchanged regardless of direction, which keeps the core connection and store management settings the same on both sides.

Selecting the Acumatica to ShipStation option also reveals an additional field called Process Flow, with two drop-down values. Shipment in ShipStation retrieves all shipments from the shipping platform. Shipment in Acumatica generates those shipments from within the ERP. These are two genuinely different data flows, and both are described below.

General Info: selecting the store that records belong to

On the General Info tab, the Get Stores button retrieves and displays all the stores currently connected on the shipping side. They are then shown in the ERP, which makes it easier for users to manage and interact with connected stores without leaving the system. The Selected checkbox next to each one determines which store is used for importing orders and shipments. If nothing is selected, there is no source or destination for the records to attach to.

Outbound: How Acumatica Orders Are Exported to ShipStation

With the Integration Option set to Acumatica to ShipStation and Process Flow set to Shipment in ShipStation, the sales order begins its life in Acumatica and is pushed out for fulfillment.

Populating the carrier, package, and warehouse tabs first

This direction exposes three reference tabs that must be filled before exports make sense. To set up each one, users open the corresponding tab and press the relevant button. Clicking Get Carriers retrieves and displays all carrier codes. Pressing Get Packages retrieves all available package types, and selecting the corresponding checkbox chooses the package to be used for the order. The ShipStation Warehouses tab operates on the same logic: press the button, review what comes back, and select what applies.

This matters because those values originate on the shipping side, not in Acumatica. Pulling them across means the exported order already carries a carrier code, a package, and a warehouse that the receiving system recognizes, rather than internal values it has never seen.

Exporting orders from the Create Orders in ShipStation screen

The Export Acu Orders screen is the bulk export point. To use it, the Integration Option of the store setup must be Acumatica to ShipStation and the Process Flow must be Shipment in ShipStation. The screen displays all orders created in Acumatica that can be exported, and the export runs against the configured Store Code and ShipStation Store ID.

Exporting a single order from the Sales Orders screen

Order export and creation can also be performed directly from the Sales Orders screen by clicking the Create ShipStation Order button under the ShipStation option in the Actions menu. This is the same operation applied to one document. It is the natural choice when a single order has to reach the warehouse immediately rather than waiting for the next bulk run.

What the ERP records when the export succeeds

When the order is exported, it is generated on the shipping side and the resulting identifier is displayed in the ShipStation Order ID field of the Sales Orders screen. That single field is the confirmation that the outbound half of the round trip completed. An order with no value there has not been created downstream, whatever else the screen shows.

Inbound: How Shipment, Tracking, and Carrier Data Return to Acumatica

Once the order is out, fulfillment happens on the shipping side. Staff pick, pack, choose a carrier and service, and generate the label using the carrier options and methods available there. The ERP is not involved in that stage, which is the point of the Biz-Tech Services ShipStation Acumatica integration: the shipping platform does shipping work, and the ERP receives the result.

Shipment confirmation and the handover to invoicing

The import does more than copy numbers. Once the shipment information is applied, the order status is updated to Prepare Invoice. That status change is the hinge between fulfillment and billing: the order leaves the shipping stage and re-enters the normal document flow, where it is invoiced through standard order processing. If an order is still sitting in its pre-shipment status, the data has not been imported yet, no matter what the shipping platform shows.

The documented workflow can be performed from the Sales Orders screen as well as from the Create Orders in ShipStation and Import Shipment from ShipStation processing screens. Both routes produce the same result, so your business can standardize on whichever fits the volume being shipped.

The Alternative Flow: Creating the Order and Shipment During Confirm Shipment

The second Process Flow option, Shipment in Acumatica, describes a different and shorter round trip. Here both the order and its shipment are created downstream from the ERP during the Confirm Shipment process, rather than the shipment being built by hand on the shipping side and then retrieved.

To create an order together with its shipment this way, users first create a Sales Order and then create a Shipment. After the shipment creation process, they manually fill in the ShipStation Information option on the Shipping tab of the Shipments screen and proceed with the Confirm Shipment process. That manual step matters, because Confirm Shipment is what triggers the transfer and it can only send what has been filled in beforehand.

After confirmation, the order and its corresponding shipment are created downstream. The returned information, including Store Code, ShipStation Store ID, ShipStation Order ID, and ShipStation Order Number, is populated in the ShipStation Information option on the Shipping tab of the Shipments screen, along with the tracking information on the Packages tab. This is the flow to choose when your business wants shipments packed and confirmed in Acumatica and only wants the shipping platform to handle carrier labels and tracking.

The Reverse Direction: Importing ShipStation Orders into Acumatica

When the store record is configured as ShipStation to Acumatica, the flow runs the other way. Orders originate downstream, typically because they came from one of the ecommerce channels the platform consolidates, and Acumatica receives them as sales orders. Based on this setup, two processing screens are enabled for retrieving and importing orders and shipments created externally: Import ShipStation Orders and Import ShipStation Shipment Orders.

Import Info: which orders are eligible to come across

The Import Info tab holds the Default Import Options, which include two key fields, Status Key and Status. These map external order statuses to corresponding statuses in Acumatica, and the mapping defines which statuses are eligible for import. If no specific status is selected, the default is to retrieve orders that have the Shipped status. The statuses eligible for mapping and import are Awaiting Shipment, Awaiting Payment, Pending Fulfillment, Shipped, On Hold, and Cancelled.

Three further fields control what the imported document becomes. Import ShipStation Orders To specifies the document type the orders will be imported into, which is how they get classified once inside. Order Type specifies the corresponding order type used for the import. Begin Order Date displays the starting date for importing orders, and only orders placed on or after that date are imported, which is what keeps a first run from reaching back through the entire history.

Bringing shipments across with the order

Two checkboxes govern shipment data on this side. When the ShipStation Shipment checkbox is selected, then during the get process on the Import ShipStation Orders screen, any shipment associated with the order is also imported and displayed under the Shipment tab on the ShipStation Orders screen. The Generate Shipment When Importing Orders checkbox enables the import of existing shipment data along with the order details, so the related shipment information arrives with the order rather than being fetched separately.

Customer and address handling on import

When the Import Customer checkbox is selected, the Biz-Tech Services ShipStation Acumatica integration imports the customer information and creates a new customer record, so details such as name, address, and contact information are accurately reflected in Acumatica. If it is not selected, orders are imported with the default customer settings from the source system instead. This choice decides whether your customer list grows with every new ecommerce buyer or stays curated.

Two override checkboxes handle addresses. Override Ship Address Information allows the incoming shipping address to override the address held in Acumatica, which ensures the order is shipped to the correct location. Override Bill Address Information imports the billing address, which may differ from the default billing information already on file. These are the settings to check first when an imported order ships or bills to an unexpected address.

Item information and SKU creation

When the Import Item checkbox is selected, the system checks whether the item exists and, if it does not, creates a new item record during the order import process. Selecting Import Item also reveals additional options: Imported Item Type, Item Class, UOM (Unit of Measure), and Warehouse ID. These define the default values used when new items are created, so they are effectively the template for every item the Biz-Tech Services Acumatica ShipStation integrator invents.

If Import Item is not selected and a new item is found during the import, the system automatically assigns default values, using Replace Missing Products for the item name and the Warehouse ID from the setup for the warehouse. Two supporting options round this out. Use Numbering Sequence for SKU Generation means that if no existing SKU (Stock Keeping Unit) number is found during item creation, a new one is generated using the numbering sequence already set up, which keeps SKUs consistent and unique. Import Images, when selected, imports and creates images for the stock item; when it is not selected, image data is not retrieved.

Tax options on imported orders

The Tax Options group controls how tax arrives with an order. When the Import Tax checkbox is selected, the system imports and displays the associated taxes, which keeps tax information synchronized between the two systems. Customer Tax Zone refers to the combined taxes that apply based on the tax zone, which is defined according to the locations of customers or vendors and determines tax rates by geographical zone. Tax ID represents the customer tax identification number, which may be required for tax reporting or compliance. Taxable Category is used to create new tax categories or edit existing ones, and those categories are applied to the products being sold so the correct taxes are applied during order processing.

Cross-references for warehouses and shipping methods

The Cross-Reference options let users select specific entities that should be matched between the two systems during the integration process. Use Cross Ref for Warehouse enables cross-referencing between warehouses on each side, so inventory is correctly mapped and synchronized. Use Cross Ref for Ship Via allows cross-referencing between shipping methods, which ensures the appropriate method is used when processing orders. Selecting these fields reveals additional tabs, Warehouse Cross Reference and Ship Via Cross Reference, where the mappings are configured.

Cross-references are the quiet fix for a whole class of data problems. Two systems rarely name the same warehouse or the same carrier service identically, and without a mapping the imported order carries a value the receiving system cannot resolve.

The Import ShipStation Orders and Import ShipStation Shipment Orders screens

The Import ShipStation Orders screen retrieves and imports all orders from the selected store ID. Pressing Get Orders retrieves and displays them. Pressing Import brings the selected orders into the Sales Orders screen. Pressing Import All brings in every order currently displayed regardless of its selection status, which is the fast path when a full batch needs to come across.

The Import ShipStation Shipment Orders screen retrieves and processes all orders that have shipments, and it does so regardless of the ShipStation Shipment checkbox setting on the store record. That exception is worth remembering: this screen ignores the checkbox that governs the other import screen.

Both screens carry the same restriction. They are functional and allow a store code to be selected only if the Integration Option of that store is configured as ShipStation to Acumatica. If it is not, the system displays an error message indicating that the corresponding store is not used to import orders.

Item and Inventory Synchronization Between Acumatica and ShipStation

Orders and shipments are only half the traffic. The Inventory Details tab on the store record, available in the ShipStation to Acumatica configuration, handles product data moving in both directions so the two catalogs describe the same goods.

1. Load Acumatica Items retrieves all Stock and Non-Stock items and displays them in a table, making the relevant inventory accessible for viewing or further processing within the Biz-Tech Services Acumatica ShipStation integration.

2. Update ShipStation Items from Acumatica exports the listed items outward, so product data downstream is updated with the latest information from the ERP.

3. Load ShipStation Items retrieves items from the shipping platform and displays them, bringing the available products into view for any necessary updates or Biz-Tech Services ShipStation Acumatica integrator processes.

4. Generate Items in Acumatica from ShipStation imports items inward. If an item exists downstream but not in the ERP, this option creates it so Acumatica reflects the products available there.

5. Load ShipStation Item by SKU retrieves one specific item using its SKU. Entering the SKU pulls the exact item across, which is the targeted option when only one product is out of step.

Keeping this catalog aligned is what prevents item-level failures further down the flow. An order that references a SKU one system does not recognize is an order that cannot be created cleanly on the other side.

What Can Go Wrong in the ShipStation Data Flow

Most problems here are configuration problems rather than transfer problems, and the documentation points at a specific set of them.

The clearest documented error is the direction mismatch. If a user opens Import ShipStation Orders or Import ShipStation Shipment Orders and tries to select a store whose Integration Option is not ShipStation to Acumatica, the system displays an error message indicating that the corresponding store is not used to import orders. The mirror image applies to the export side: Create Orders in ShipStation and Import Shipment from ShipStation both require the Integration Option to be Acumatica to ShipStation with Process Flow set to Shipment in ShipStation, so a store configured any other way will not drive them.

The second common cause is scope rather than error. Begin Order Date excludes anything placed before the configured date. The Status Key and Status mapping excludes any order whose status was never mapped, and with nothing selected the default is to retrieve only Shipped orders. The Selected checkbox on General Info excludes any store that was not chosen. In each case the Biz-Tech Services Acumatica ShipStation integrator is working exactly as configured and simply has no reason to move the record.

The third is credentials. Because the Consumer Key, Consumer Secret, and Base URL authenticate every API call, an expired or mistyped value stops all traffic in both directions at once. The Test Credentials button on the Connection Settings tab is the fastest way to rule this in or out before investigating anything else.

Where to Monitor ShipStation Results in Acumatica

The Biz-Tech Services Acumatica ShipStation connector writes its results into specific, checkable places. When a user asks what happened to an order, these are the fields and screens that answer the question:

  • ShipStation Order ID on the Sales Orders screen: populated once the order has been exported and created downstream. Empty means the export did not complete.
  • The order status on the Sales Orders screen: updated to Prepare Invoice once shipment information has been imported.
  • The Import Shipment from ShipStation screen: it displays all orders that have already been exported, so it doubles as a list of what made it across.
  • The Create Orders in ShipStation screen: it displays all orders that can still be exported and created, which is effectively the outbound backlog.
  • The shipment number and tracking number added to the corresponding order after the shipment is imported.
  • The ShipStation Information option on the Shipping tab of the Shipments screen: after Confirm Shipment in the Shipment in Acumatica flow, it holds the Store Code, ShipStation Store ID, ShipStation Order ID, and ShipStation Order Number.
  • The Packages tab of the Shipments screen: it carries the tracking information written back after the order and shipment are created from Acumatica.
  • The Shipment tab on the ShipStation Orders screen: when the ShipStation Shipment checkbox is selected, any shipment associated with an imported order appears here.
  • The ShipStation Orders generic inquiry: it displays the initial conditions of the imported orders.
  • The ShipStation Shipments generic inquiry: it displays all initial information about the shipment orders.
  • The General Info tab of the store record: the list returned by Get Stores and the Selected checkbox confirm which store the Biz-Tech Services Acumatica ShipStation integration is actually using.
  • The Connection Settings tab: the Test Credentials button confirms whether Acumatica can still reach the shipping platform through the API at all.

ShipStation Acumatica Integration: Frequently Asked Questions

How do orders get from Acumatica to ShipStation?

Orders are exported either in bulk from the Create Orders in ShipStation screen or one at a time from the Sales Orders screen, using the Create ShipStation Order button under the ShipStation option in the Actions menu. The export uses the configured Store Code and ShipStation Store ID to decide which store receives the order. Both routes require the store record to have Integration Option set to Acumatica to ShipStation and Process Flow set to Shipment in ShipStation.

Why did an order not export to ShipStation?

Start with the ShipStation Order ID field on the Sales Orders screen: if it is empty, the order was never created downstream. The most common reason is that the store record is not configured for that direction, because Create Orders in ShipStation only works when the Integration Option is Acumatica to ShipStation and the Process Flow is Shipment in ShipStation. Also confirm the credentials still pass the Test Credentials check on the Connection Settings tab, since a failed connection stops every export.

Why is the tracking number missing on my Acumatica order?

The tracking number arrives only when the shipment is imported back, either from the Import Shipment from ShipStation screen or through the Get Shipstation Shipments button in the Actions menu of the Sales Orders screen. If that import has not run, or if no shipment exists yet for that order, there is nothing to write back. A reliable secondary check is the order status: if it has not moved to Prepare Invoice, the shipment information was not applied.

What is the difference between Shipment in ShipStation and Shipment in Acumatica?

These are the two Process Flow options available when the Integration Option is Acumatica to ShipStation. Shipment in ShipStation retrieves all shipments from the shipping platform, so the shipment is built there and imported afterwards. Shipment in Acumatica generates those shipments from within Acumatica, so the order and its shipment are both created during the Confirm Shipment process.

How do I import ShipStation orders into Acumatica?

Set the store record Integration Option to ShipStation to Acumatica, then use the Import ShipStation Orders screen. Press Get Orders to retrieve and display everything available, then Import to bring the selected orders into the Sales Orders screen, or Import All to bring in every order currently displayed regardless of selection. If you specifically need orders that already have shipments, use the Import ShipStation Shipment Orders screen instead.

Which order statuses can be imported into Acumatica?

The statuses eligible for mapping and import are Awaiting Shipment, Awaiting Payment, Pending Fulfillment, Shipped, On Hold, and Cancelled. The mapping is done with the Status Key and Status fields under Default Import Options on the Import Info tab. If no specific status is selected, the default is to retrieve orders with the Shipped status, which is why a store that was never mapped appears to import almost nothing.

Why does the store code field not accept my store on the import screens?

Import ShipStation Orders and Import ShipStation Shipment Orders are functional and allow a store code to be selected only if the Integration Option of that store is configured as ShipStation to Acumatica. If it is configured the other way, the system displays an error message indicating that the corresponding store is not used to import orders. Either switch to a store set up for imports, or reconsider which direction that store is meant to serve.

Does the connector keep item data in sync?

Yes, through the Inventory Details tab on the store record. Load Acumatica Items and Update ShipStation Items from Acumatica push product data outward, while Load ShipStation Items, Generate Items in Acumatica from ShipStation, and Load ShipStation Item by SKU bring product data back in. Generate Items in Acumatica from ShipStation is the option that creates an item in Acumatica when it exists downstream but not here.

Work With the Biz-Tech Services ShipStation Connector

This data flow is a loop with clear checkpoints. Credentials and the Integration Option decide what is possible, the export writes an order identifier onto the sales order, the shipping platform does the picking, carrier selection, and label generation, and the import writes the shipment number and tracking number back and moves the order to Prepare Invoice. In the reverse direction, orders, customers, addresses, taxes, and items flow inward through the Import ShipStation Orders and Import ShipStation Shipment Orders screens. Knowing which field to check at each checkpoint turns most support questions into a ten-second answer.

If your business runs fulfillment through ShipStation and accounting through Acumatica ERP, the Biz-Tech Services Acumatica ShipStation connector can carry orders, shipments, tracking data, and items across that gap without manual re-entry. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration.

The post How ShipStation Data Flows Between Shipping and Acumatica ERP appeared first on Biz-Tech Services.

]]> How ShipHero Data Flows Between WMS and Acumatica ERP https://biz-techservices.com/archives/10322 Tue, 11 Aug 2026 04:27:25 +0000 https://biz-techservices.com/?p=10322 How ShipHero Data Flows Between WMS and Acumatica ERP ShipHero data flows into Acumatica ERP as a round trip: orders, […]

The post How ShipHero Data Flows Between WMS and Acumatica ERP appeared first on Biz-Tech Services.

]]> How ShipHero Data Flows Between WMS and Acumatica ERP

ShipHero data flows into Acumatica ERP as a round trip: orders, purchase orders and return orders travel out of Acumatica to ShipHero, the Warehouse Management System (WMS) picks, packs and ships them, and shipments, tracking numbers, labels, receipts, bin transfers and return receipts travel back into Acumatica to close the documents out. The Biz-Tech Services ShipHero Acumatica Connector is the customization that carries records in both directions, and it is built around one central configuration screen – the ShipHero Store – that decides which way each record is allowed to move.

Understanding that round trip is what makes the Biz-Tech Services Acumatica ShipHero connector predictable. Most of the questions users raise after go-live are not really integration questions; they are questions about which checkbox on the ShipHero Store told a record to move, which cross-reference translated a value from one system to the other, and which inquiry screen shows what the WMS sent back. This article walks the whole path in the order records actually travel: package installation and credentials first, then outbound documents, then inbound fulfillment, then item and inventory sync, and finally the screens and fields your business checks to confirm that each hop worked.

What the ShipHero Connector for Acumatica Does

ShipHero is a warehouse management and order fulfillment platform built to streamline logistics and supply chain processes for eCommerce businesses. Acumatica is a cloud-based enterprise resource planning (ERP) system that manages finance, inventory and customer relationships. The Biz-Tech Services ShipHero Acumatica integrator is the software integration that sits between them and handles communication and data exchange, so that the fulfillment side and the ERP side stay on the same set of records instead of two teams keying the same order twice.

The Biz-Tech Services Acumatica ShipHero integrator is delivered as an Acumatica customization package and published through the Customization Projects screen (SM204505). That screen is where you add the customization project, validate it, and publish it for a tenant or several tenants; the platform uploads the selected package, creates the corresponding customization project and saves it in the database. Once the project is published, the ShipHero screens – the ShipHero Store, the processing screens, and the ShipHero Order, Shipment, Item, Vendor and Purchase Order inquiries – become available inside your ERP.

What the Biz-Tech Services ShipHero Acumatica connector does not do is guess. Every document type, warehouse, carrier, box and reason code that crosses the boundary has to be either explicitly enabled or explicitly mapped on the ShipHero Store first. That is deliberate: it means a misconfigured record fails to appear on a processing screen rather than silently creating the wrong document in Acumatica.

The ShipHero Data Flow at a Glance

Here is the full round trip between Acumatica and the ShipHero WMS, in the order the records move:

1. Install and publish the ShipHero customization package on the Customization Projects (SM204505) screen, then open the ShipHero Store screen and enter the ShipHero Username, ShipHero Password and Base URL on the Connection Settings area of the General Info tab. Use Test Credentials to confirm the API connection before anything else.

2. Choose the Integration Option on the ShipHero Store header – either ShipHero to Acumatica or Acumatica to ShipHero. This single field determines the direction of travel and which tabs the store displays.

3. Map the values that differ between the two systems: Ship Via Cross-Reference for carriers, Warehouse Cross-Reference for warehouses, Box Mapping for the Acumatica Box ID against the ShipHero box name, and Reason Code Mapping for returns.

4. Sync master data both ways from the Inventory Details, Locations and Vendors tabs – Load Acumatica Items and Sync Acumatica Items push outward; Load ShipHero Items and Sync ShipHero Items pull inward.

5. Send documents out to the warehouse: Sales Orders through the Export ShipHero Order screen, purchase orders through Export Purchase Orders to ShipHero, and RC return orders through Export Return Orders To ShipHero.

6. ShipHero fulfills the work – it picks and ships the order, generates the shipping label and tracking number, receives the purchase order, moves stock between bins, and receives returns.

7. Bring the results back: Import Shipments from ShipHero confirms the Acumatica shipment, Import Receipts from ShipHero creates the purchase receipt, Import Bin Transfers from ShipHero creates the transfer, and Import Return Order Receipt from ShipHero creates the return document.

8. Optionally switch the whole inbound side to real time by enabling Use Webhook on the ShipHero Store header and registering shipment, PO receipt, return receipt and transfer webhooks on the Webhook Settings tab.

9. Monitor everything on the ShipHero Order, ShipHero Shipment, ShipHero Item, ShipHero Vendor and ShipHero Purchase Order inquiry screens, and on the Shipments tab of the related Sales Order.

Setup: Installing the Package and Configuring the ShipHero Store

Nothing moves until the customization is published and the store is configured. This is the part of the flow your business only does once, but every later behaviour traces back to a decision made here.

How do you install the ShipHero package in Acumatica?

The Biz-Tech Services ShipHero Acumatica connector is installed through the Customization Projects screen, Form ID SM204505. From that form you can add a new customization project – a set of changes and additional files that modify the Acumatica ERP application – open the project in the Customization Project Editor, validate one or several projects, publish a project for one tenant or multiple tenants, cancel a publication, view the XML of a published project, export the project as a deployment package, import a project from an existing deployment package, or delete a project. When you upload the ShipHero package, the platform creates the corresponding customization project and saves it in the database; publishing it is what makes the screens live.

Where do ShipHero credentials go?

Credentials live on the Ship Hero Store Credentials screen. The Connection Settings area of the General Info tab holds the ShipHero Username, ShipHero Password and Base URL – the ShipHero system credentials used during integration. Two buttons govern them: Test Credentials checks that Acumatica can reach ShipHero over the API using exactly what is on the Connection Settings tab, and Edit Credentials unlocks the fields so they can be changed. Run Test Credentials before you touch any processing screen, because a store whose credentials never validated will simply return nothing when you press Get Orders or Get Shipments, with no document to inspect afterwards.

The header of the store also carries the identifying fields. ShipHero Store Code is a lookup field that points at the corresponding store in the WMS, and Description labels it for your users. The Default Store checkbox matters more than it looks: when it is selected, that store code is the one displayed during all sync processes initiated from Acumatica, which is what keeps a multi-store setup from making users pick a store on every single action.

What does the Integration Option actually change?

The Integration Option field determines the workflow direction, and it changes which tabs the ShipHero Store even displays. Set to ShipHero to Acumatica, the system brings data from the WMS into the ERP: it retrieves and imports all shipped orders together with the labels and tracking numbers already generated in ShipHero. In that mode the store shows the General Info, Import Info, Ship Via Cross Reference, Warehouse Cross Reference, Inventory Details, Sync Info and Locations tabs.

Set to Acumatica to ShipHero, the flow reverses: orders are created in the ERP and exported to ShipHero, you ship them in the WMS, and the shipments come back into Acumatica. That mode adds tabs the other direction does not need, including Box Mapping, Vendors, Order Types To Export and – once a receipt order type exists – Reason Code Mapping. If a tab you expect is missing, the Integration Option is almost always the reason.

Which import defaults should you set first?

The Import Info tab carries the Default Import Options, which populate automatically once credentials are set. Import ShipHero Orders To specifies the document type that ShipHero orders land in and is a drop-down offering Sales Order or Invoice. Order Type shows the document type the order should be imported into. Import Freight controls whether the order freight comes across at all – clear it and freight is not imported. Last Imported Order Date sets the date boundary for the first order to be imported, which is how you keep a first sync from dragging in years of history.

Two checkboxes on the same tab control mapping: Use Cross Ref for Ship Via and Use Cross Ref for Warehouse. Selecting either makes the corresponding cross-reference tab appear on the store so ShipHero values can be matched to Acumatica values. Tax behaviour sits alongside them – selecting Import Tax brings ShipHero order taxes across and exposes the Customer Tax Zone (the combined effective tax for a zone, defined by the vendor or customer locations), Tax ID (the customer tax ID) and Taxable Category, which is used to create or edit the tax categories applied to products.

How does the connector decide which customer an imported order belongs to?

Customer resolution happens in two places, and knowing the order of precedence saves a lot of confusion. On the General Info tab, the Stores to Get grid has a Customer column that sets an individual default customer per store, plus a Last Import Date showing when the last order was imported and a Selected checkbox that tells the system which stores orders and shipments should be imported from. If the Customer field on that grid is null, the system falls back to the Customer Information setup during order importation.

On the Customer Information tab, selecting Import Customer makes the Biz-Tech Services Acumatica ShipHero integrator create a new customer record from the ShipHero customer data, and exposes a Customer Class field for the default class assigned to those new customers. Leave Import Customer cleared and orders import against the single default customer named in the Customer field instead. Two override checkboxes sit here as well: Override Ship Address Information from ShipHero Order imports the address the order ships to, and Override Bill Address Information from ShipHero Order imports the billing address of whoever pays the order.

What handles packaging?

On the Packaging tab, clearing the Automatic Packaging checkbox reveals a Default Box ID field. Choose the box there, then select Automatic Packaging so that the default package is used with the order. In the Acumatica to ShipHero direction there is also a Box Mapping tab, where users map the Acumatica Box ID value to the ShipHero box name so a package created on one side is recognisable on the other.

Cross-References: Translating Values Between Acumatica and ShipHero

Cross-references are the quiet backbone of the whole data flow. They exist because the same real-world thing – a carrier, a warehouse, a return reason – carries different identifiers in each system, and a record that cannot be translated is a record that stops.

Ship Via Cross-Reference

The Ship Via Cross-Reference tab lets you select the entities that should be set up and matched in ShipHero and Acumatica during the transition. This mapping is what turns a carrier and service returned by the WMS into a Ship Via that Acumatica recognises, and it is also called out as a prerequisite for exporting returns.

Warehouse Cross-Reference

The Warehouse Cross-Reference tab is used by two separate processes: the item sync process and the order import process. Based on this setup, the Biz-Tech Services ShipHero Acumatica integrator imports orders and assigns the mapped warehouse to the sales order screen. The same mapping applies to items – when items sync from ShipHero, the warehouse is created for the item according to this setup. It also constrains the Locations tab, because locations are only loaded for warehouses that have been set up on Warehouse Cross-Reference.

Order Types To Export and Reason Code Mapping

In the Acumatica to ShipHero direction, the Order Types To Export grid defines which Acumatica order types are allowed to leave for the WMS. Each row has an Active checkbox, and only when Active is selected can orders of that type be exported. You can also set up a receipt order type such as RC here. As soon as at least one receipt order type exists, a new Reason Code Mapping tab appears, whose grid contains Active and Is Default checkboxes; when a return order is exported, this grid maps the reason code onto the order lines.

Outbound: How Acumatica Documents Reach the ShipHero WMS

With the store configured, records begin moving. Each outbound document type has its own processing screen, and each has its own admission rule about which records are eligible to appear there.

How do sales orders get exported to ShipHero?

The Export ShipHero Order screen exports Acumatica orders to the WMS, provided the corresponding setup exists in the ShipHero Store. Two conditions decide whether an order is even listed: the order must have an Open status in Acumatica, and its order type must have been set up in the selected store. An order that fails either test does not appear on the screen at all – it does not appear with an error. Pressing Export creates the order in ShipHero.

How do purchase orders reach ShipHero?

The Export Purchase Orders to ShipHero screen exports purchase orders so the warehouse knows what inbound stock to expect. Only purchase orders with an Open status appear on this screen. There is no special store setup required for it. An Export to ShipHero button has also been added and can be added manually, which lets users determine all the purchase orders that should be exported.

How do return orders get exported?

The Export Return Orders To ShipHero screen handles returns going out. If the RC order type is configured in the ShipHero Store under the Order Types to Export tab, RC orders appear on this processing screen and can be exported. Clicking Load Return Orders loads and displays all orders with the RC order type; Export sends a selected order and Export All sends all of them at once. The screen also supports an automatic scheduler, so return exports can run unattended, and the export can equally be performed from the Sales Order actions.

The return round trip has a strict sequence, and the Customer Order Number field is the key that holds it together. First create a Sales Order and set a value in Customer Order Number. Create the shipment for that order in ShipHero and import the shipment back into Acumatica; once the shipment is imported, the order status in Acumatica updates to Completed. Only then create a new order with the RC (Return for Credit) order type, for the same customer, containing the same item or items, and with a Customer Order Number that matches the original sales order. During the return process the system uses the Customer Order Number value to identify and match the correct customer associated with the returned order. After the export, the system generates and displays the ShipHero returned order ID and number. Reason Code and Ship Via mappings must exist between the two systems for return exports to work.

Inbound: How Fulfillment, Tracking and Shipments Come Back to Acumatica

The inbound leg is where the warehouse tells the ERP what actually happened. Each inbound screen follows the same two-button pattern – a Get action that pulls raw records from the WMS onto a staging inquiry, and an Import action that turns them into real Acumatica documents. That separation is useful: it lets users inspect what ShipHero sent before it becomes an accounting document.

How do you import orders created in ShipHero?

The Import ShipHero Orders screen retrieves orders from the WMS. Select the ShipHero Store Code to specify which store orders should be retrieved from. Get Orders pulls the orders across and adds them to the ShipHero Order screen, and Import then creates the Sales Order based on the setup in the store – the document type, freight, tax, customer and warehouse decisions you made on the Import Info, Customer Information and Warehouse Cross-Reference tabs.

How do shipments and tracking numbers come back?

The Import Shipments from ShipHero screen gets and imports all shipments from the WMS. ShipHero orders with an Open status or Sales Order status are displayed here. Notably, both store directions can be shown on the ShipHero Store Code field of this screen – both ShipHero to Acumatica and Acumatica to ShipHero stores – because both flows eventually need shipments back. Get Shipments retrieves the shipments, which are then displayed on the Shipments tab of the ShipHero Order screen, and Import imports the shipment into Acumatica and confirms it.

That confirmation is the point of the whole outbound leg. In the ShipHero to Acumatica direction, the Biz-Tech Services Acumatica ShipHero integration retrieves and imports shipped orders along with the labels and tracking numbers already generated in the WMS, so your business is not rekeying carrier data. The label and package information for each shipment can be found on the Packages tab of the ShipHero Shipment screen.

How do purchase receipts come back?

The Import Receipts from ShipHero screen imports purchase receipts for purchase orders that were previously exported. Get Receipts pulls receipts from the WMS and displays the ones that need to be imported; Import creates the receipt for the purchase order. Whether that receipt is released automatically is governed by the Release PO Receipt During Import Process checkbox on the Sync Info tab of the store: selected, receipts are released automatically on import; cleared, receipts are imported unreleased. If a receipt is imported partially, the last imported receipt is released.

How do bin transfers come back?

The Import Bin Transfers from ShipHero screen imports transfer bins based on the dates selected on the Sync Info tab of the ShipHero Store screen. It imports the transfers and displays them on the Transfers screen, and each line shows which location an inventory ID was transferred from and which location it went to, within the same warehouse. The Release Transfer During Import Process checkbox controls whether those transfers are released automatically on import. One hard prerequisite applies: this screen only works when the Multiple Warehouse Locations checkbox is selected.

How do return receipts come back?

The Import Return Order Receipt from ShipHero processing screen imports all returns from the WMS into Acumatica. After returns are exported and return records exist in ShipHero, you can set the tracking number and generate a return label there. Once the return is ready, it can be retrieved and imported into Acumatica and assigned to the corresponding RC order type. Import handles a selected order and Import All handles them all, an automatic scheduler can be configured for the process, and returns can also be imported directly from the Sales Order actions. When a return is imported, the system creates a return document in Acumatica and adds it to the Shipments tab of the related Sales Order, including the tracking number.

Item, Location and Vendor Sync Between Acumatica and ShipHero

Documents only flow cleanly when the master data underneath them matches. The ShipHero Store carries three sync surfaces – Inventory Details for items, Locations for bins, and Vendors – plus a Sync Info tab that defines what happens when the Biz-Tech Services Acumatica ShipHero integration meets something it has never seen before.

How does item sync work in both directions?

The Inventory Details tab loads and displays both Acumatica and ShipHero items. Load Acumatica Items loads and displays all items in Acumatica, and Sync Acumatica Items exports them to the WMS. Load ShipHero Items loads and displays all items in ShipHero, and Sync ShipHero Items imports them into Acumatica; during that import, if a stock item has a vendor or vendors already synced to ShipHero, the vendor information is synced with the item as well. Purge deletes everything currently displayed on the Inventory Details table, and Select All selects every item, with a second press clearing the selection.

What happens when an item does not exist in Acumatica?

This is what the Import Item checkbox on the Sync Info tab decides, and it is one of the highest-impact settings in the Biz-Tech Services ShipHero Acumatica connector. Selected, the system is allowed to create a new item when it does not exist during the sync and order import processes, and it exposes Imported Item Type, Item Class, UOM and Warehouse ID fields that define the defaults for that new item. Cleared, the system does not create new items at all: when a new item arrives, it sets the default value of Replace Missing Products as the item name and takes the warehouse from the Warehouse ID field, assigning that same default item to every new item it meets.

The same tab controls what values are pushed outward. Export Price Type selects whether the default item price or the MSRP is exported, and Export Price Quantity selects whether the On Hand, Available, or Available for Shipment quantity is sent. That second field deserves thought – exporting On Hand when your business allocates stock heavily will tell the warehouse it has inventory that is already committed elsewhere.

How do warehouse locations sync?

The Locations tab is gated by the Multiple Warehouse Locations checkbox, which becomes selected when the button is activated from the Enable/Disable screen. With it selected, the Sellable Location, Non-Sellable Location, Release Transfer During Import Process and Begin Bin Transfers Date fields become available. Use Location Mapping then decides the granularity: select it and a grid appears for mapping locations one by one; leave it cleared and two locations should be set up instead.

Sellable Location and Non-Sellable Location determine the default values for sellable and non-sellable quantities in Acumatica when a purchase order is exported and a receipt is created in the WMS. There is an important exception to remember: when you create a sales order in Acumatica, export it to ShipHero and import the shipment back, the Sellable location on the lines is always set. The Locations grid itself works like Inventory Details – Load Acumatica Locations loads all Acumatica locations, Sync Acumatica Locations exports them to the WMS, Load ShipHero Locations loads all locations in ShipHero, Purge clears the grid, and Select All toggles the whole selection. Locations are only loaded for warehouses that have been set up on the Warehouse Cross-Reference tab.

How do vendors sync?

The Vendors tab loads and displays both Acumatica and ShipHero vendors and syncs them between the two systems, with Purge to clear the displayed table and Select All to toggle the selection. Before running the Sync Acumatica Vendors action, the Default Vendor Class ID must be selected on the Sync Info tab – that field also drives the Sync ShipHero Vendors button, which generates ShipHero vendors in Acumatica under the chosen class. This vendor information is used by the shipment import process from ShipHero to Acumatica.

Real-Time Flow: ShipHero Webhook Settings

Everything described so far is pull-based – a user or a scheduler presses Get and then Import. The Webhook Settings tab replaces that rhythm with real-time synchronization, so the WMS pushes events into Acumatica as they happen.

How do you set up ShipHero webhooks?

Enabling Use Webhook in the ShipHero Store header makes the Webhook Settings tab available; that tab defines which events are received from ShipHero and how they are processed. On the Webhooks screen, the Webhook Name must be selected and must match the value set as Webhook Type in the Webhook Settings tab of the store – if Webhook Name and Webhook Type do not match, the webhook will not work. Once the URL is generated on the Webhooks screen, set it in the Webhook Settings tab and press Create Webhook, which creates the webhook URL and sends it to ShipHero for POST requests. The same URL can be created for only one webhook and set only once; attempting to reuse it produces an error stating that the URL already exists.

A Branch for Webhooks must also be selected. All incoming webhook data – shipments, PO receipts, transfers and returns – is processed under that branch, and if no branch is selected, webhooks will not work at all.

Which events can ShipHero push into Acumatica?

Shipment webhooks cover the core fulfillment loop: Get Shipment listens for shipment events from ShipHero in real time, and Import Shipment automatically imports the received shipment data into Acumatica and matches the shipment to the corresponding Sales Order. This also supports a WMS-first pattern – a sales order can be created in ShipHero and exported to Acumatica, and once a shipment is created in ShipHero the webhook retrieves and imports it and automatically matches it with the corresponding Sales Order.

Get PO Receipt listens for PO receipt events and Import PO Receipt automatically creates PO receipts and updates received quantities for purchase orders, so receipts are reflected immediately in inventory. Get Return Receipt listens for return receipt events so returned items captured in the WMS can be processed according to your return workflows. Get Transfer listens to inventory transfer events and Import Transfer automatically imports them, updating stock movement between warehouses and locations in real time.

What do the webhook grid fields mean?

Each row in the webhook grid at the bottom of the tab is one webhook registration. Webhook Type defines the event type, such as Inventory Change, Shipment or PO Receipt. Webhook URL is the URL generated and registered for that webhook. Registered indicates the webhook was successfully registered with ShipHero, and Enabled indicates it is active and processing events. Create Webhook registers the webhook and sends its URL to ShipHero for POST requests, Enable Webhook activates the selected webhook and starts real-time synchronization, and Disable Webhook deactivates it and stops incoming events while the configuration remains saved.

Where to Monitor ShipHero Results in Acumatica

When users ask what happened to an order, these are the exact screens, tabs and fields to check, roughly in the order you would walk the flow:

  • ShipHero Store, General Info tab – Test Credentials confirms the API connection, and the Last Import Date column in the Stores to Get grid shows when the last order was imported for each store.
  • ShipHero Store, Import Info tab – Last Imported Order Date shows the date boundary the Biz-Tech Services ShipHero Acumatica connector is working from, which explains most cases of “older orders never arrived”.
  • Export ShipHero Order screen – if an Acumatica order is missing here, its status is not Open or its order type is not set up in the selected store.
  • ShipHero Order screen – the header shows the order ID, Store Code, the order status in Acumatica and the ShipHero order number, plus the order status in ShipHero, the financial part of the order, the ship via and customer addresses.
  • ShipHero Order, Details tab – the products that were ordered, as ShipHero has them.
  • ShipHero Order, Addresses tab – the customer addresses that came across, which is where you verify the Override Ship Address and Override Bill Address behaviour.
  • ShipHero Order, Shipments tab – the shipment ID for the order, rendered as a hyperlink that takes you straight to the ShipHero Shipment screen.
  • ShipHero Shipment screen – the shipment detail, with the Packages tab holding the label and package information, and the Processed checkbox, which is selected automatically when the shipment is processed from the processing screens.
  • ShipHero Item inquiry – the Warehouse Details tab shows item availability, the Vendors tab shows the vendor the item is connected to in ShipHero, and the Bin Transfers tab shows transfers for the item. Update Item displays all changes made to the ShipHero item, Sync ShipHero Item syncs the item into Acumatica, and Update Warehouse In ShipHero syncs and updates the item quantity in the WMS.
  • ShipHero Purchase Order inquiry – synced purchase order data from Acumatica to ShipHero, where Update Order brings back to Acumatica all changes made to the synced purchase order in the WMS.
  • ShipHero Vendor inquiry – ShipHero vendor information, useful when the shipment import process is not resolving a vendor.
  • Transfers screen in Acumatica – bin transfers imported from ShipHero appear here, with the from and to locations on each line.
  • Shipments tab of the related Sales Order – after a return is imported, the return document is added here including the tracking number, and after a shipment is imported the sales order status moves to Completed.
  • Webhook Settings tab grid – the Registered and Enabled columns tell you whether a webhook is actually live, which is the first thing to check when real-time events stop arriving.

ShipHero Acumatica Integration: Frequently Asked Questions

Which direction does the ShipHero Connector move data?

Both, and the Biz-Tech Services ShipHero Acumatica Integration Option field on the ShipHero Store decides which one a given store handles. ShipHero to Acumatica retrieves and imports shipped orders with the labels and tracking numbers already generated in the WMS. Acumatica to ShipHero lets you create orders in Acumatica, export them, ship them in ShipHero and bring the shipments back. Your business can configure separate stores for each direction, and the Import Shipments from ShipHero screen shows both types.

Why did an order not reach ShipHero?

Start with the Export ShipHero Order screen. Only Acumatica orders with an Open status appear there, and the order type must have been set up in the selected ShipHero Store under Order Types To Export with the Active checkbox selected. If either condition fails, the order is simply not listed rather than flagged, so check status and order type setup before looking anywhere else. For returns specifically, the RC order type must be configured under Order Types to Export or RC orders will not appear on the Export Return Orders To ShipHero screen.

Why is tracking not coming back from ShipHero?

Tracking numbers arrive with the shipment, so the question is really why the shipment has not been imported. Check that Get Shipments was run on the Import Shipments from ShipHero screen and that the shipment is listed on the Shipments tab of the ShipHero Order screen, then that Import was run – it is the Import action that brings the shipment into Acumatica and confirms it. If you are relying on webhooks instead, confirm that the shipment webhook shows Registered and Enabled, that the Branch for Webhooks is selected, and that Webhook Name on the Webhooks screen matches Webhook Type in the Webhook Settings tab.

Why are my webhooks not working?

There are three documented causes. The Webhook Name selected on the Webhooks screen must match the Webhook Type value in the Webhook Settings tab of the ShipHero Store, or the webhook will not work. A Branch for Webhooks must be selected, because all incoming shipment, PO receipt, transfer and return data is processed under that branch. And the same URL can only be created for one webhook and set once – reusing it raises an error stating the URL already exists.

Why is the Import Bin Transfers screen not returning anything?

The Import Bin Transfers from ShipHero screen only works when the Multiple Warehouse Locations checkbox is selected. That checkbox becomes selected when the button is activated from the Enable/Disable screen. Also check the Begin Bin Transfers Date on the Locations tab and the dates on the Sync Info tab, because the screen imports transfers based on the dates selected there.

Why did an imported order come in with the wrong item?

That is the Import Item checkbox on the Sync Info tab. When it is cleared, the Biz-Tech Services Acumatica ShipHero connector does not create new items in Acumatica; instead it sets the default value of Replace Missing Products as the item name and takes the warehouse from the Warehouse ID field, assigning that default to every unrecognised item. If your business wants real items created automatically, select Import Item and set the Imported Item Type, Item Class, UOM and Warehouse ID defaults that appear.

Do purchase receipts and transfers release automatically?

Only if you tell them to. Release PO Receipt During Import Process on the Sync Info tab releases receipts automatically on import; when it is cleared, receipts are imported as not released, and if a receipt is imported partially, the last imported receipt is released. Release Transfer During Import Process does the same for transfers imported from ShipHero.

How does the connector match a return to the original order?

Through the Customer Order Number field. The original Sales Order must carry a value in Customer Order Number, and the RC (Return for Credit) order must be created for the same customer, contain the same items, and use the same Customer Order Number. The system uses that value during the return process to identify and match the correct customer associated with the returned order. Reason Code and Ship Via mappings must also exist between Acumatica and ShipHero values for return exports to work.

Work With the Biz-Tech Services ShipHero Connector

The ShipHero data flow is a loop, not a one-way feed. Documents leave Acumatica through the export screens, the WMS does the physical work and generates labels, tracking numbers, receipts and transfers, and the import screens – or the webhooks, if you run in real time – bring that reality back so sales orders, purchase orders and returns close out correctly. The ShipHero Store is where every one of those hops is authorised, from the Integration Option that sets direction, through the cross-references that translate carriers, warehouses, boxes and reason codes, to the Sync Info defaults that decide what happens when the two systems disagree. Get the store right and the monitoring screens become a formality; get it wrong and records quietly stop appearing on the processing screens.

If your business is running Acumatica alongside a ShipHero warehouse and wants the round trip configured properly the first time, the Biz-Tech Services ShipHero Connector team can help scope the store setup, the cross-references and the webhook configuration around how you actually fulfill. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration.

The post How ShipHero Data Flows Between WMS and Acumatica ERP appeared first on Biz-Tech Services.

]]> How Magento Data Flows into Acumatica ERP https://biz-techservices.com/archives/10313 Mon, 10 Aug 2026 21:39:42 +0000 https://biz-techservices.com/?p=10313 How Magento Data Flows into Acumatica ERP Magento data flows into Acumatica ERP through a connector that retrieves orders from […]

The post How Magento Data Flows into Acumatica ERP appeared first on Biz-Tech Services.

]]> How Magento Data Flows into Acumatica ERP

Magento data flows into Acumatica ERP through a connector that retrieves orders from your Magento store, imports the selected orders as Acumatica documents, and then generates fulfillment events back in Magento once the resulting shipments are confirmed. Everything else the Biz-Tech Services Magento Acumatica integration does, customer creation, payment handling, tax defaults, item creation, inventory quantity updates, and refund processing, hangs off that same inbound-then-outbound path. Understanding the order in which records move is the fastest way to know which setting to change when something does not arrive where you expect it.

The product described here is the Biz-Tech Services Magento Connector for Acumatica ERP, built by Biz-Tech Services, Inc. It links Magento, the e-commerce platform, with Acumatica, the enterprise resource planning system, using connection settings entered in Acumatica and an Application Programming Interface, or API, connection to your store. This article walks the data flow in the order records actually travel: setup and credentials first, then inbound orders, then the customer, payment and tax decisions made during import, then outbound fulfillment, then item and inventory synchronization, and finally where errors surface and what a user checks to confirm the result.

What the Magento Connector for Acumatica Does

The Biz-Tech Services Acumatica Magento Connector is an Acumatica ERP customization that connects a Magento e-commerce store to the back office so that the two systems share orders, customers, and item data. The Biz-Tech Services Acumatica Magento integration requires connection settings on the Magento Store screen. Based on those settings, the Biz-Tech Services Magento Acumatica connector reaches the corresponding store and retrieves orders, and imports the selected orders into Acumatica ERP. When a user confirms the shipments created from those imported orders, fulfillment events are generated in the store for each corresponding order. The Biz-Tech Services Acumatica Magento Integrator also requires default options and the required values for the order import process, which is why the configuration screens matter as much as the processing screens.

The Biz-Tech Services Acumatica Magento integrator is delivered as an Acumatica customization project and is installed from the Customization Projects form, screen ID SM204505. That form is where you add the project, validate it, and publish it for a tenant, and it is also where the publication can later be cancelled or the project exported as a deployment package. The Biz-Tech Services Magento Acumatica integrator must be installed on an Acumatica system carrying one of the following licenses: PCSR, PERP, or SAAS.

The Magento Data Flow at a Glance

Before looking at individual fields, here is the whole path a record travels between the two systems:

  • Credentials are entered and tested on the Magento Credentials screen, where Store Code, Description, Default Store, Username, Password, and Base URL define the connection, and Test Credentials confirms that Acumatica can reach the store through the API.
  • The Magento Store screen holds the configuration that determines the overall functionality of the Biz-Tech Services Acumatica Magento integrator: order import, item import and creation, payment processing, customer management, shipping options, and warehouse settings.
  • Get Orders on the Import Magento Orders screen retrieves the orders, and the processing grid lists only those that hold a qualifying status in the store.
  • Import or Import All creates the Acumatica document defined by Import Magento Orders To and Order Type, applying the customer, payment, tax, discount, item, and warehouse defaults configured on the store screen.
  • The Magento Orders screen records the imported order and links it forward through the Sales Order Number and Invoice Number fields, so a user can trace an order into the Acumatica document chain.
  • Fulfillment runs in Acumatica, and confirming the shipment generates the fulfillment event in Magento, with the Prepare Invoice and Release Invoice steps governed by their own skip and quantity-check settings.
  • Outbound item processes push items, product images, inventory quantities, multi-prices, categories, and publication status from Acumatica to Magento, while the matching import processes pull items and multi-prices back the other way.
  • Refunded orders are retrieved separately on the Import Magento Refunded Orders screen and processed into Customer Refund payments or credit memos depending on how far the original order has progressed.

Each setting discussed below sits at one of those handoffs, which is why a change on the Magento Store screen can alter the outcome of a process run several screens later.

Stage One: Magento Credentials and the Connection to Your Store

Setup begins on the Magento Credentials screen, which is where users set up the credentials that connect the two platforms and make the Biz-Tech Services Magento Acumatica integration between them possible. Store Code functions as a lookup field that identifies the corresponding store, and Description is used to provide a description of that store. Because the connector supports more than one store record, the Store Code is the value that every downstream processing screen uses to decide which store it is talking to.

Selecting the Default Store checkbox marks the store as the default store. This matters more than it looks: on processing screens where a Store Code has to be chosen before anything is retrieved, a default store removes a repeated selection step and reduces the chance of running a process against the wrong store.

What the Connection Settings tab controls

Username, Password, and Base URL are the Magento system credentials used to configure the connection settings. The information specified on the Connection Settings tab is used to test the ability of the system to connect to the store through the API. Test Credentials tests that connection using the credentials from the Connection Settings tab, so it is the correct first check whenever nothing is being retrieved at all. Edit Credentials allows editing of the store credentials, and Redirect to Store Settings opens the Magento Store screen, which is the natural next step once the connection is proven.

Stage Two: The Magento Store Screen Governs the Whole Flow

The configuration defined on the Magento Store screen determines the overall functionality of the Biz-Tech Services Acumatica Magento Connector. It controls the order import process, item import and creation, payment processing, customer management, shipping options, warehouse settings, and other related operations. Users who treat this screen as a one-time setup task tend to misdiagnose later problems, because most unexpected import results trace back to a checkbox or default value here rather than to the processing screen where the problem was noticed.

Default Import Options: what is retrieved and from when

Get Magento selects which Magento entities to retrieve into the Acumatica system. Import Magento Orders To specifies where the orders are imported in Acumatica, and Order Type is the default type of orders to be created by the Biz-Tech Services Acumatica Magento integration. Together those two fields decide what kind of Acumatica document an order turns into, so they should be settled before the first production import rather than after.

Begin Order Date allows the data retrieval to be filtered, which is how your business avoids pulling the entire order history of the store on the first run. Two read-only companions record what has already happened: Last Imported Order Date is the date when the last order was imported, and Last Refunded Order Date is the date when the last refunded order was imported. Get Refunded Data when Receiving Orders retrieves refunded orders during the Get Order process, so refunds can be collected in the same pass rather than as a separate exercise.

Error notifications during order import

Send Email Notifications for Errors informs the user about any errors encountered during the process. An email notification feature exists for failed orders during the order import process, which ensures that users are promptly alerted if an order import encounters issues or failures. Notifications go to the email address added on the order settings tab. They are sent during batch imports and during process updates for the same order, because the system checks all orders again for the selected period during that process. For a store that imports on a schedule, this notification is the practical difference between finding a failed order the same day and finding it at month end.

Inbound: How Magento Orders Become Acumatica Documents

The Import Magento Orders screen allows users to retrieve and import all orders from the store into Acumatica. It is the main inbound entry point, and it is deliberately a two-step screen: retrieval and import are separate actions, so nothing is created in Acumatica simply because it was fetched.

Retrieving orders with Get Orders

The Get Orders button retrieves orders from Magento. After the button is clicked, a timer indicates the elapsed time until the process is complete, and a user can cancel the process of getting orders by clicking the loading icon next to the timer. The processing page shows only orders that hold the statuses Partially Shipped, on hold, Pending, and Processing in the Magento shop. That status filter is the single most common reason an order that exists in Magento never appears in the Acumatica grid.

The Import button enables the import of selected orders into Acumatica. Alternatively, the Import All button imports all orders displayed on the grid. Selective import is worth using during the first weeks of a go-live, because it lets your business validate the resulting documents order by order before switching to bulk runs.

Reading the Magento Orders screen

When orders are retrieved and displayed on the Import Magento Orders screen, each order carries a hyperlink, and clicking the order number navigates to the corresponding Magento Orders screen. That screen presents the initial status of the order and is the record your business returns to when tracing what happened to a given order.

The screen consists of several tabs. Document Details provides information about the items of the order. Addresses provides details about the customer address. Refund Info becomes visible only if the order has been refunded, displaying the relevant refund information. CC Payment provides information about the credit card payment method.

The header fields are where results are read. Order Number displays the Magento order ID. The Magento order status reflects the initial state of the order upon import. Status displays the Magento order status inside Acumatica. Payment Method displays the payment method used for the order, and Ship Via indicates the shipping method used. Sales Order Number displays the sales order number of the order once it is imported, and Invoice Number displays the invoice number once the order is invoiced. Those two fields are the link between the e-commerce record and the Acumatica document chain.

The amount fields complete the picture: Total Lines Amount displays the total sum of item lines, Discount Total displays the discount total for the order, Shipping Total displays the total amount of shipping, Total Tax displays the tax total, and Total shows the order total including taxes and other charges.

The three actions on the Magento Orders screen

Refresh Order updates the Magento order status in Acumatica. This matters because the status stored at import time is the initial state; if the order is later fulfilled in Magento, opening the actions menu and clicking Refresh Order updates the status of the order to match the store. Receive Orders enables the retrieval of individual orders into Acumatica by choosing the store code and setting the order ID, which is the targeted alternative to a full Get Orders run. Import Order, when selected on the corresponding Magento Orders screen, displays a confirmation popup asking whether you want to create a sales order for that order in Acumatica.

Customers, Payments, Taxes, and Discounts During Magento Order Import

The decisions the Biz-Tech Services Acumatica Magento integrator makes while an order is being imported are all configured on the Magento Store screen. These are the settings that determine whether a customer record is created, whether a payment document is produced, which tax defaults are applied, and how discounts land on the resulting Acumatica document.

Customer Information options

Import Customer means the Biz-Tech Services Magento Acumatica integration imports the customer information from Magento into a new customer record in Acumatica. Customer Class is the default customer class set on new customers that do not exist in Acumatica and are created by the Biz-Tech Services Acumatica Magento integration, so it is the field that decides which account and terms defaults a new web customer inherits.

Override Ship Address Information imports the address information of the location the order is going to be shipped to from Magento, and Override Bill Address Information imports the address information of the party who will pay the bill of the order from the store. Notify Customer for Shipment Confirmation means the Biz-Tech Services Magento Acumatica integrator notifies the customer when the order is shipped, if the checkbox is selected. Use Default Group ID allows a default group ID to be selected for the customer sync process, and Default Password for Customers allows a default password to be selected for the new customers being created in Magento.

Payment Options

Skip Magento Payment, when selected, means the order is imported from Magento without payment. That is the right choice when payment capture is handled entirely outside Acumatica. Payment Method is the payment method set on the payment during the order import process, and Payment Type is the type of payment that determines the payment type of the imported order. Release Payment during Order Import releases the payment during the Magento order import process, which removes a manual step but also commits the payment document immediately, so it should be enabled only once the mapping is proven.

Use Credit Card Payment, when selected, displays the CC Payment Mapping tab on the Magento Store screen, allowing the user to configure the corresponding mapping for the credit card payment method used for the order imported into Acumatica. The result of that mapping is what a user later reads on the CC Payment tab of the Magento Orders screen.

Tax Options

Tax ID is the default tax ID set on the orders. Customer Tax Zone is the combined tax of the effective taxes for a particular zone, defined according to the locations of the vendors or customers. Taxable Category is used to create tax categories, or edit existing tax categories, that are applied to products. Is Freight Included In Magento indicates that freight is being taxed in Magento, which is the setting that keeps the two systems from disagreeing about the tax on shipping.

Discount Option

Calculate Discount On Order Lines determines where discounts appear on the resulting document. When it is selected, the system calculates discounts per line, populating the Discount Amount and Discount Code fields in the Sales Orders Document Details table. Alternatively, the system calculates discounts for the entire order and provides the details in the Discount section. The choice affects reporting as much as data entry, because line-level discount data is what makes margin analysis by item possible.

Outbound: Fulfillment Events Sent Back to Magento

Once a Magento order has become an Acumatica document, fulfillment proceeds in Acumatica and the Biz-Tech Services Magento Acumatica integration reports the result back. When a user confirms the shipments created from the imported orders, fulfillment events are generated in the store for each corresponding order. If Notify Customer for Shipment Confirmation is selected on the Magento Store screen, the Biz-Tech Services Acumatica Magento Integration notifies the customer when the order is shipped.

Two Export Default Options on the Magento Store screen control what leaves Acumatica during invoicing. Skip Magento Shipment while Prepare Invoice means the Biz-Tech Services Acumatica Magento connector does not send a shipment creation request to Magento during the Prepare Invoice process in Acumatica. Skip API Request While Release Invoice means the Biz-Tech Services Magento Acumatica integrator sends no API request at all during the invoice release process. Both are useful when a business deliberately handles shipment records on the store side, and both are worth checking first when an expected update never reaches the store.

Two related item settings guard stock at the same points in the flow. Check Magento Qty While Prepare Invoice validates the product quantities in the store during the invoice preparation process, confirming that the required stock is available before the invoice is created. Check Magento Qty While Release Invoice validates the same quantities during the invoice release process to ensure sufficient stock is available. These checks put the quantity validation at the moment the financial document is created rather than after the fact.

Refunds: How Magento Refunded Orders Are Processed in Acumatica

Import Magento Refunded Orders allows users to import refunded orders from the store into Acumatica. The Get Orders button loads the refunded orders onto the screen, after which they can be imported. The system then manages the refunded order import based on how far the original order has already progressed in Acumatica, which is why the same Process button produces different documents in different situations.

  • Case 1, when the refunded order is a sales order in Acumatica that has not progressed with any fulfillments and consists of a single item: pressing Process generates a payment with a Customer Refund type, attaches it to the Payments tab, sets the refunded amount, and closes the order. The sales order status changes to Canceled and all lines are deleted.
  • Case 1, when the order consists of several items and is refunded: the refunded quantity is reduced from the order quantity, and the system creates a payment document and attaches it on the Payments tab for the refunded items, while the order status remains Open.
  • Case 2, when an order shipment has been created but not confirmed: clicking Process triggers the system to find the created shipment, delete it, and then proceed with the actions of Case 1.
  • Case 3, when an order shipment has been confirmed: clicking Process results in the system creating a credit memo and attaching a reference number with Customer Refund type to the Applications.
  • Case 4, when the invoice is prepared but not released: the system creates a credit memo and attaches a reference number with Customer Refund type to Applications after the refunded order is processed.
  • Case 5, when the invoice is released: the system reverses the invoice and generates a credit memo with a Customer Refund type in the reference number attached to Applications.

After those actions, the Processed checkbox on the Refunds tab is automatically checked on the Magento Orders screen for the corresponding order, which means the process is over and the order is Closed. To verify the financial side, follow the Reference number to view the Customer Refund type payment and the refunded amount on the Application History tab.

Customer Export: Sending Acumatica Customers to Magento

The customer export process can be run from the Customers screen as well as from the Export Magento Customer processing screen. On the Customers screen, the Sync Magento Customer button in the Actions command toolbar performs the customer export. Selecting that action from the Actions command menu is what sends the customer to the store.

The Biz-Tech Services Acumatica Magento connector syncs a customer only if three conditions are met, and each one is a common cause of a customer that silently fails to appear in the store. First, the Customer Price Class, which corresponds to Magento customer groups, must exist in both systems. Second, the customer must have a contact. Third, that contact must have a First Name, a Last Name, an Email, and a Magento Customer Password, and the password must be a mixture of letters, numbers, and special characters.

After the customer export process completes, the Magento Customer checkbox becomes checked on the Customers screen and the Magento Customer ID is added under the Magento Customers tab of the Customers screen. Those two indicators are the confirmation a user should look for rather than assuming the export worked. Customer groups themselves are handled on the Customer Groups tab of the Magento Store screen, where customer groups are synced to the Acumatica Customer Price Class.

Item and Inventory Synchronization Between Acumatica and Magento

Item data moves in both directions, and the Magento Store screen carries the settings that decide what is created, what is matched, and which quantity number is sent.

Item Information settings that govern item creation

If the Import Item checkbox is selected, new items are created in Acumatica during the synchronization of orders from Magento, based on the configured settings. If the checkbox is not selected, the program prohibits the import and creation of items unless the corresponding items have already been created in Acumatica. The system searches for the Inventory CD using the Magento Product SKU. If it is found, the system retrieves that item; if it is not found, an error message is displayed stating that the item does not exist in the system.

Import Item Type specifies the item type that should be created, and Item Class selects the item class for imported items, which groups stock or non-stock items with similar properties and provides default settings for new items. Warehouse ID is the default warehouse set on the orders imported from Magento, and UOM, the unit of measure, is used to quantify the inventory items. Replace Missing Products replaces Magento items that do not exist in Acumatica with a selected item during the order import process, if the Import Item checkbox is disabled, which keeps an order importable rather than blocking it on one unrecognized SKU.

Several further options tune the item side of the flow. Use Bulk Sync Items Functionality syncs one hundred items at once, but only if the RabbitMQ module is set up in the Magento system. Import Items on Inventory Details Tab retrieves items to the Inventory Details tab of the Magento Store screen while orders are being imported. Import Product Images allows images to be synced during synchronization if the item has one attached. Date Last Received Item indicates the last date used for retrieving products, which is the item-side equivalent of the order date trackers.

The Inventory Details tab

On the Inventory Details tab of the Magento Store screen, a user can load the items held in both systems and then sync, publish, or unpublish them in the store. Load Acumatica Items retrieves all Acumatica stock and non-stock items and displays them in the table, and the Load Magento Items button retrieves the store catalog the same way. Sync to Magento exports Acumatica items outward, and Sync from Magento brings items back into the Acumatica system.

The supporting buttons make bulk work practical. Check All selects all the items displayed in the table, and clicking it a second time unchecks them. Get Item retrieves a specified item by item SKU or name. Purge deletes all the items displayed in the table. Publish Items in Magento enables the publication of selected items in the store, setting their status to Enabled, and Unpublish Items in Magento removes the Enabled status from the selected items, making them unavailable for purchase. The item details list can be exported and imported as an Excel document.

When items are synced from Acumatica to Magento, a new item is created there and a unique ID for the item is generated. That unique ID is displayed in the Acumatica Magento store record and on the Magento Inventory tab of the stock item. The processes of item synchronization, item publishing, and item unpublishing can also be carried out on the Stock Items and Non-Stock Items screens, so a user working on a single item does not have to return to the store screen.

Warehouse Details and which quantity is sent

The Warehouse Details tab is where the warehouses whose quantities need to be in sync with Magento are added. If one or more warehouses are selected there, the exported item quantity displays the sum of quantities across the selected warehouses. The quantity that is synced from Acumatica to Magento depends on the selected drop-down value: On hand, Available, or Available for Shipment. That choice is worth deliberating over, because it decides whether your store advertises physical stock or committed-adjusted stock.

The outbound item processing screens

Export Magento Inventory Quantities is the screen for syncing Acumatica inventory quantities to Magento. Beforehand, the required items must be chosen on the Inventory Details tab of the Magento Store screen by checking the checkboxes and pressing Save, and the Magento Product SKU and Acumatica Inventory ID fields must also be set on that tab. Only after those actions do items appear on the Export Magento Inventory Quantities processing screen. To sync a quantity, enter the corresponding quantity in the Magento Quantity field for the item, check the checkbox, and click Sync; the item quantity in the store is updated based on that value. Sync All syncs the quantities of all items displayed on the screen.

Export Magento Items allows the export of Acumatica items outward. Items appear on that screen if the Magento Product SKU is set on the item tab of the Magento Store screen. Select the items and export them by pressing Sync or Sync All. After the synchronization process, the Price, Description, Weight, Length, Height, Width, and Category of the item are updated in the Magento shop. If the Biz-Tech Services Magento Acumatica connector does not find some items in the store during synchronization, it creates them automatically. Once the item has been synced, the Magento Item checkbox is checked and the Magento Product ID is added under the Magento Inventory tab of the Items screen.

Export Magento Product Images handles images: if an item has an attached image, the system exports it to the store from this screen. Select the corresponding items and export them by pressing Sync or Sync All.

Multi-price export and import

Item prices can differ based on clients, expiration date, and other factors, and the Export Item Multi-Prices screen exports item multi-prices from Acumatica to Magento. Items appear on that screen only if three conditions are met: the items must be selected and saved on the Magento Store screen, the items must have the Magento Product SKU field set on the Inventory Details tab of that same screen, and they must be added on the Sales Prices screen with their corresponding sales prices. Select the Store Code, check the items whose prices should be exported, and click Export or Export All. After synchronization, the sales price of the item is updated in the Magento store as its sales price.

Import Item Multi-Prices moves the same data the other way, importing item multi-prices from Magento to Acumatica. The same conditions must be met for the required items to appear on the screen. Select the Store Code, check the items whose prices should be imported, and click Import or Import All.

Importing Magento items into Acumatica

The Import Magento Items screen allows you to import Magento items along with their corresponding price, weight, and image into Acumatica. Run the Get Items process, after which the items are displayed on the screen, then select the corresponding items and click Import or Import All to import them into Acumatica. This is the catalog-first path for businesses whose product data is maintained in Magento rather than in the ERP.

Mapping: Cross-References, Attributes, and Categories

Mapping is what keeps the two systems agreeing on the meaning of a value, and it is configured on the Magento Store screen. Cross-Reference options select the entities that should be matched in Magento and Acumatica during the transition. The entities checked in Cross-Reference Options then appear in the drop-down field on the Cross-Reference tab, where Field selects the entity whose values should be matched and the Magento Value and Ship Via columns specify the values that correspond to each other. Separately, the Export Fields to Magento tab is where a user chooses which fields should be updated in the store during the item sync process.

The Inventory Mappings tab organizes the mapping that makes the sync of Acumatica attributes and user defined fields to Magento attributes possible. On that tab you add the properties of the particular attribute that you should choose on the Attributes tab of the Item Class screen. If the Magento property attribute does not exist in the shop, the sync process is not possible, so the store side has to be prepared first.

The Attribute Details tab loads the active options of a particular attribute. Retrieving them requires that the attribute properties have been added on the Inventory Mappings tab. Once the mappings are configured correctly, the active options for the attribute can be retrieved on the Attribute Details tab by pressing the Load Active Attribute Options button. The active options cannot be retrieved if the Acumatica attribute control type and the Magento attribute control type do not match, which is the first thing to check when the button returns nothing.

The Category Details tab exports and imports product categories. To retrieve product categories from Magento, click Get Magento Categories, or create a new category in Acumatica, choose it, and save; then press Sync Magento Categories to generate the new category in the store as well. The product categories list can be exported and imported as an Excel document. Attribute Sets is where a user gets Magento attribute sets.

Where to Monitor Magento Results in Acumatica

The Biz-Tech Services Acumatica Magento connector writes its results into specific fields, checkboxes, and tabs rather than into a single log, so knowing where to look is part of running it. These are the places a user checks to see what actually happened:

  • The Import Magento Orders grid after Get Orders, including the timer that indicates elapsed time until the retrieval process is complete.
  • The Status field on the Magento Orders screen, which displays the Magento order status in Acumatica, refreshed with the Refresh Order action when the order has since been fulfilled in the store.
  • The Sales Order Number field on the Magento Orders screen, which displays the sales order number of the order once it is imported.
  • The Invoice Number field on the same screen, which displays the invoice number once the order is invoiced.
  • The amount fields on the Magento Orders screen: Total Lines Amount, Discount Total, Shipping Total, Total Tax, and Total.
  • The Document Details tab for the items of the order, the Addresses tab for the customer address, and the CC Payment tab for the credit card payment method.
  • The Refund Info tab, which becomes visible only if the order has been refunded, and the Processed checkbox on the Refunds tab, which is checked automatically once refund processing is complete and the order is Closed.
  • The Payments tab of the sales order for the Customer Refund payment, and the Application History tab reached through the Reference number to confirm the refunded amount.
  • The Magento Customer checkbox on the Customers screen and the Magento Customer ID under the Magento Customers tab, which together confirm a successful customer export.
  • The Magento Item checkbox and the Magento Product ID under the Magento Inventory tab of the Items screen, plus the unique ID shown on that same tab of the stock item after a sync to Magento.
  • The Last Imported Order Date, Last Refunded Order Date, and Date Last Received Item fields on the Magento Store screen, which show how far each retrieval process has progressed.
  • The error email sent to the address on the order settings tab when Send Email Notifications for Errors is selected, which reports failed orders during batch imports and process updates.

Magento Acumatica Integration: Frequently Asked Questions

How do I connect Magento to Acumatica?

Connection settings are entered on the Magento Credentials screen, where you supply the Store Code, Description, Username, Password, and Base URL, and optionally mark the record as the Default Store. The information on the Connection Settings tab is used to test whether the system can connect to the store through the API, and the Test Credentials button runs that test. Once the credentials are valid, Redirect to Store Settings opens the Magento Store screen, where the rest of the configuration is defined.

Why is a Magento order not appearing on the Import Magento Orders screen?

The processing page shows only orders that hold the statuses Partially Shipped, on hold, Pending, and Processing in the Magento shop, so an order in any other status will not be listed. The Begin Order Date field on the Magento Store screen also filters data retrieval, which means orders older than that date are excluded. If nothing at all is retrieved, run Test Credentials on the Magento Credentials screen to confirm that Acumatica can still reach the store through the API. For a single known order, the Receive Orders action on the Magento Orders screen retrieves it directly by store code and order ID.

Why was a customer not created in Magento during the export?

The Biz-Tech Services Magento Acumatica connector syncs a customer only when three conditions are met. The Customer Price Class, which corresponds to customer groups, must exist in both systems; the customer must have a contact; and that contact must have a First Name, a Last Name, an Email, and a Magento Customer Password made up of a mixture of letters, numbers, and special characters. If the export appeared to run but nothing arrived, check whether the Magento Customer checkbox was set and whether a Magento Customer ID appears under the Magento Customers tab of the Customers screen.

Why does an order import fail saying the item does not exist in the system?

During order import the system searches for the Inventory CD using the Magento Product SKU. If the SKU is not found and the Import Item checkbox is not selected, the program prohibits the import and creation of the item and displays that error, because it will only use items that already exist in Acumatica. Selecting Import Item lets new items be created during order synchronization based on the configured settings, and Replace Missing Products offers the alternative of substituting a selected item for Magento items that do not exist in Acumatica while Import Item remains disabled.

Can I import Magento orders without payment information?

Yes. Selecting Skip Magento Payment on the Magento Store screen means the order is imported without payment. When payment is imported, Payment Method sets the payment method used during the Magento order import process and Payment Type determines the payment type of the imported order, while Release Payment during Order Import releases the payment as part of the import. Use Credit Card Payment adds the CC Payment Mapping tab so that credit card methods can be mapped explicitly.

What happens in Acumatica when a Magento order is refunded?

Refunded orders are loaded on the Import Magento Refunded Orders screen with Get Orders and then handled by the Process button, and the outcome depends on the stage of the original order. An unfulfilled single-item order produces a Customer Refund payment, the order closes, and the sales order status changes to Canceled with its lines deleted. A multi-item refund reduces the refunded quantity and attaches a payment while the order remains Open. Once a shipment has been confirmed, or an invoice prepared or released, the system produces a credit memo instead, reversing the invoice first in the released case.

How do I publish or unpublish Magento items from Acumatica?

Use the Inventory Details tab of the Magento Store screen. Publish Items in Magento enables the publication of the selected items in the store and sets their status to Enabled, while Unpublish Items in Magento removes the Enabled status and makes those items unavailable for purchase. The same item synchronization, publishing, and unpublishing processes can also be carried out from the Stock Items and Non-Stock Items screens.

Which Acumatica license does the Magento Connector require?

The Biz-Tech Services Acumatica Magento Connector must be installed on an Acumatica system with one of the following licenses: PCSR, PERP, or SAAS. Installation itself is performed on the Customization Projects form, screen ID SM204505, which is used to add the customization project, validate it, and publish it for one or more tenants.

Work With the Biz-Tech Services Magento Connector

The Magento data flow into Acumatica ERP is a single path with configurable branches. Credentials on the Magento Credentials screen open the connection; the Magento Store screen sets the defaults that govern order import, customer creation, payments, taxes, discounts, items, and warehouses; Get Orders and Import move the orders in; fulfillment in Acumatica sends events back out; the item, image, quantity, and multi-price processes keep the catalog aligned in both directions; and refunds are reconciled according to how far the original order had already travelled. Once your business knows which screen owns which decision, tracing any individual record through Acumatica becomes a short exercise rather than an investigation.

If your business runs a Magento store alongside Acumatica ERP and wants order, customer, and inventory data to move between them without manual re-entry, the Biz-Tech Services Magento Acumatica Connector is built for exactly that. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration.

The post How Magento Data Flows into Acumatica ERP appeared first on Biz-Tech Services.

]]> NetSuite to Acumatica Migration Guide 2026: Why Companies Switch and How to Migrate Successfully https://biz-techservices.com/archives/10295 Mon, 10 Aug 2026 05:30:56 +0000 https://biz-techservices.com/?p=10295 The post NetSuite to Acumatica Migration Guide 2026: Why Companies Switch and How to Migrate Successfully appeared first on Biz-Tech Services.

]]>

NetSuite to Acumatica Migration Guide 2026

NetSuite to Acumatica Migration Guide 2026: Why Companies Switch and How to Migrate Successfully

Moving from Oracle NetSuite to Acumatica is not a normal software upgrade. It is an ERP-to-ERP transformation.

A business making this move is rarely starting with a clean accounting database. A mature NetSuite environment may contain years of financial history, several subsidiaries, multiple currencies, warehouses, open orders, inventory, custom records, custom segments, SuiteScript applications, saved searches, workflows, dashboards, SuiteApps, eCommerce integrations, EDI connections, payment platforms, warehouse systems, shipping tools, CRM applications, tax engines, and business rules that have evolved over many years.

That is why a NetSuite to Acumatica migration must be approached as a complete business transformation rather than a file conversion.

Companies researching Acumatica vs NetSuite usually begin by comparing functionality, usability, integrations, implementation, licensing philosophy, customization, reporting, industry fit, partner ecosystems, and long-term ERP cost.

But once a company decides that its current ERP is no longer the right fit, the question changes.

How do we leave NetSuite without losing the data, integrations, controls, reporting, and business processes our company depends on?

That is the purpose of this guide.

Acumatica has an established migration path for organizations moving away from NetSuite, and multiple businesses have publicly documented successful transitions from NetSuite to Acumatica.

Those migrations demonstrate an important point: companies do not usually replace ERP simply because another platform has a longer feature list. They replace ERP because the relationship between business value, cost, complexity, usability, integrations, support, customization, and future growth has changed.

A successful NetSuite migration to Acumatica should therefore solve more than the immediate reason for leaving NetSuite. It should create a cleaner, more maintainable, more connected ERP environment for the next stage of the company’s growth.

As an Acumatica Gold Partner, BizTech helps businesses plan, implement, customize, integrate, test, migrate, train, and support Acumatica environments.

BizTech also develops proprietary Acumatica connectors and enhancements for eCommerce, marketplaces, payments, warehouses, fulfillment, shipping, CRM, EDI, inventory processing, and specialized business workflows.

That combination is especially relevant for companies leaving NetSuite because a mature NetSuite environment is rarely isolated.

The migration may involve:

  • financial data and general ledger history;
  • subsidiaries, departments, classes, locations, and reporting dimensions;
  • customers, vendors, contacts, and addresses;
  • inventory, assemblies, matrix items, prices, lots, and serial numbers;
  • open sales orders, purchase orders, invoices, bills, credits, and payments;
  • projects, fixed assets, budgets, and historical transactions;
  • NetSuite custom fields and custom records;
  • SuiteScript business logic;
  • SuiteFlow workflows;
  • saved searches, reports, and dashboards;
  • SuiteApps and third-party applications;
  • eCommerce and marketplace integrations;
  • warehouse, shipping, EDI, CRM, payment, and tax integrations.

The goal is not to copy every NetSuite object into Acumatica.

The goal is to preserve what creates business value, eliminate unnecessary technical debt, and design a new ERP environment around Acumatica’s strengths.

Why Companies Consider Leaving NetSuite

NetSuite is a mature cloud ERP platform. A serious NetSuite replacement guide should acknowledge that directly.

Companies do not normally replace a mature ERP because it suddenly stops processing transactions. They replace it because the relationship between business value, cost, flexibility, usability, support, technical dependency, and future requirements no longer works for them.

Common reasons organizations begin researching a NetSuite alternative include:

  • the commercial model no longer fits the company;
  • the organization wants broader ERP access across more employees;
  • customization and technical maintenance have become expensive;
  • the business depends too heavily on specialized NetSuite developers;
  • reporting requires too much custom work;
  • integrations are difficult to maintain;
  • industry-specific requirements are not being handled efficiently;
  • the existing implementation accumulated significant technical debt;
  • users find the ERP difficult to adopt;
  • support or partner relationships are no longer delivering sufficient value;
  • a contract renewal has triggered a broader ERP evaluation;
  • the company wants a different licensing, deployment, integration, or support philosophy.

A migration project should not begin with the assumption that every problem was caused by NetSuite itself.

Some issues may be caused by poor original implementation, excessive customization, incorrect processes, outdated integrations, bad data, insufficient user training, or years of uncontrolled changes.

Before migrating, the company should document:

  • why NetSuite is being replaced;
  • which business problems must be solved;
  • which NetSuite functionality must be preserved;
  • which processes should be redesigned;
  • which third-party applications should remain;
  • which customizations should be retired;
  • what measurable outcomes Acumatica must deliver.

Without this step, the company risks spending significant money to recreate the same problems inside a different ERP.

Acumatica vs NetSuite After Years of ERP Ownership

An ERP comparison looks different after a company has already lived with ERP for several years.

A first-time buyer may ask whether the system supports inventory, multiple entities, CRM, manufacturing, eCommerce, or project accounting.

An experienced ERP customer asks harder questions:

  • How expensive is it to change processes?
  • How difficult is it to add users?
  • How much specialized development do we need?
  • Can we understand our own integrations?
  • Can managers create useful reports without development?
  • What happens when transaction volume doubles?
  • How difficult are upgrades?
  • How responsive is the partner ecosystem?
  • Can the ERP adapt as our business model changes?

This is where Acumatica often becomes attractive.

Acumatica is designed around:

  • open architecture;
  • APIs and webhooks;
  • configurable workflows;
  • low-code and no-code functionality;
  • industry-specific editions;
  • partner-led implementation;
  • growth-friendly user access;
  • modern browser-based ERP architecture.

A company migrating from NetSuite can use the project as an opportunity to redesign its ERP around those principles.

What Changes After Moving from NetSuite to Acumatica?

The objective should not be to make Acumatica look exactly like NetSuite. Acumatica has a different platform philosophy.

Unlimited User-Oriented Pricing Philosophy

Acumatica promotes unlimited user access with pricing tailored around applications and resource consumption.

That can change ERP adoption. Instead of designing access primarily around user-seat economics, a company can ask: Who should have direct access to live ERP data?

That may include:

  • warehouse users;
  • project managers;
  • supervisors;
  • sales representatives;
  • customer service;
  • purchasing;
  • finance;
  • executives;
  • field teams.

Broader participation can improve data quality, process discipline, and visibility.

Open Architecture

Acumatica supports:

  • REST APIs;
  • webhooks;
  • business events;
  • import and export scenarios;
  • configurable workflows;
  • customization projects;
  • developer extensions.

For integration-heavy organizations, this provides an opportunity to redesign the technology stack around clearer and more maintainable interfaces.

Industry Editions

Acumatica provides industry functionality for:

  • distribution;
  • manufacturing;
  • construction;
  • retail and commerce;
  • professional services;
  • field service;
  • project-based organizations.

A migration can therefore be designed around industry workflows instead of building every operational requirement through custom ERP code.

Partner-Led Delivery

Acumatica operates through its partner ecosystem.

The selection of an Acumatica implementation partner therefore becomes central to project success.

The partner normally plays a major role in discovery, configuration, migration, integration, customization, training, and support.

Real Companies That Replaced NetSuite with Acumatica

Published Acumatica customer stories demonstrate that NetSuite-to-Acumatica migration is already a real ERP scenario.

These results belong to specific companies and should not be treated as universal guarantees. They are useful because they show different migration patterns.

Quantum Group: Seven Companies on One Acumatica Platform

Quantum Group is a manufacturing and distribution company that replaced NetSuite with Acumatica Manufacturing Edition.

The business needed to manage financials across seven companies in three physical locations, support multiple users, improve reporting, and reduce problems associated with its previous ERP environment.

The published case study reports:

  • seven companies managed on one platform;
  • IT cost savings;
  • a 30-day migration and implementation for that particular project;
  • the ability to add users without additional user license fees.

The important lesson is not that every NetSuite migration takes 30 days.

The case demonstrates that a well-scoped multi-company migration can move to Acumatica without reproducing the commercial and operational model of the old ERP.

NuvoH2O: Omnichannel Operations and Lower Software Costs

NuvoH2O replaced a heavily customized NetSuite environment with Acumatica Distribution Edition.

The published case study reports:

  • a 69% reduction in software costs during the first year;
  • a 67% faster month-end close, from 15 days to 5 days;
  • doubling of business and transaction volume;
  • integration with BigCommerce, Amazon, and SPS Commerce;
  • implementation in approximately six months for that project.

This case is particularly relevant for distribution and eCommerce companies because the target ERP was designed around inventory, warehouse management, real-time reporting, and open integrations.

cbdMD: NetSuite Replacement in High-Volume Manufacturing

cbdMD moved from NetSuite to Acumatica Manufacturing Edition.

The published case study reports:

  • approximately $200,000 in annual software licensing savings;
  • 30% faster order fulfillment;
  • significantly higher shipment capacity;
  • improved inventory cycle counting;
  • integration with Shopify and quality-management software.

The architectural lesson is important: the company did not only migrate accounting.

Acumatica became a platform for manufacturing, distribution, warehouse management, CRM, compliance workflows, and integrations.

Shoebacca: Reducing IT Dependency

Online retailer Shoebacca replaced NetSuite and a homegrown warehouse system with Acumatica.

The published case study reports lower IT staffing requirements, concurrent ERP access for more than 40 employees, multiple entities managed on one platform, and greater integration flexibility.

What Can Be Migrated from NetSuite to Acumatica?

Most business-critical NetSuite data can be migrated, but there is rarely a perfect one-to-one object match.

The migration should be organized by business meaning rather than source table alone.

Organization and Financial Structure

  • subsidiaries;
  • locations;
  • departments;
  • classes;
  • custom segments;
  • chart of accounts;
  • currencies;
  • accounting periods;
  • tax settings;
  • intercompany relationships;
  • consolidation structures.

Customer Data

  • customers;
  • contacts;
  • billing addresses;
  • shipping addresses;
  • terms;
  • credit limits;
  • tax registrations;
  • sales representatives;
  • price levels;
  • custom fields;
  • customer hierarchy;
  • external IDs.

Vendor Data

  • vendors;
  • contacts;
  • addresses;
  • payment terms;
  • tax identifiers;
  • currencies;
  • payment information;
  • custom fields;
  • external IDs.

Inventory and Product Data

  • inventory items;
  • non-inventory items;
  • service items;
  • assemblies;
  • kits;
  • matrix items;
  • variants;
  • units of measure;
  • prices;
  • vendors;
  • warehouse relationships;
  • lot and serial information;
  • inventory quantities;
  • cost information;
  • reorder parameters;
  • attributes and custom fields.

Open Transactions

  • sales orders;
  • purchase orders;
  • customer invoices;
  • vendor bills;
  • credit memos;
  • payments;
  • deposits;
  • returns;
  • transfer orders;
  • open projects;
  • other active operational documents.

Historical Transactions

Depending on the selected strategy:

  • general ledger history;
  • sales history;
  • purchasing history;
  • inventory transactions;
  • payment history;
  • project history;
  • fixed asset history;
  • bank activity;
  • attachments and documents.

Customization Metadata

The migration should also inventory:

  • custom fields;
  • custom record types;
  • custom forms;
  • custom segments;
  • saved searches;
  • workflows;
  • SuiteScripts;
  • SuiteApps;
  • custom reports;
  • dashboard configurations.

These customization objects are not normally imported into Acumatica unchanged.

Their business purpose must be assessed and rebuilt using the appropriate Acumatica functionality.

How NetSuite Data Is Extracted for Migration

One of the most technical parts of a NetSuite data migration is extraction.

NetSuite provides several mechanisms for retrieving data.

Full CSV Export

NetSuite includes a Full CSV Export capability.

However, Full CSV Export does not necessarily provide every category of information required to reconstruct a complete ERP environment.

A serious migration should therefore not assume that one export function will create a complete dataset that can simply be imported into Acumatica.

Saved Search Exports

Saved searches are often among the most useful migration tools because the extraction team can define:

  • record type;
  • criteria;
  • results;
  • joins;
  • internal IDs;
  • external IDs;
  • filters;
  • custom fields.

Saved search results can be exported as CSV files.

Migration-specific searches can be created for customers, vendors, items, locations, transactions, open balances, custom records, and integration cross-references.

Report Exports

NetSuite financial and operational reports can be exported and used as reconciliation control sources.

This is particularly important when validating Acumatica balances after migration.

SuiteAnalytics Connect

For larger datasets, SuiteAnalytics Connect may provide structured access to NetSuite data for repeatable extraction and transformation pipelines.

SuiteTalk Web Services

Web services can be used to query NetSuite records programmatically where structured extraction is required.

SuiteScript-Based Extraction

For specialized environments, SuiteScript may be used to extract information that is not conveniently available through standard exports.

File Cabinet and Attachments

Documents and files require a separate migration or archival strategy.

The company should decide which documents should move to Acumatica, which should remain archived, how files should be linked to migrated records, and which content is subject to retention requirements.

NetSuite Saved Search Migration

Saved searches deserve special attention because many organizations effectively use them as operational applications.

They may control:

  • work queues;
  • warehouse exceptions;
  • customer service processes;
  • integration exports;
  • management reports;
  • collections;
  • inventory decisions;
  • approval reviews.

For each important saved search, document:

  • business owner;
  • record type;
  • criteria;
  • columns;
  • formula fields;
  • joins;
  • scheduled delivery;
  • dashboard usage;
  • integration dependencies.

A NetSuite saved search may become:

  • an Acumatica Generic Inquiry;
  • a dashboard widget;
  • a financial report;
  • a standard report;
  • a business event;
  • a workflow condition;
  • an integration endpoint;
  • a Power BI dataset;
  • something that is no longer required.

The correct target is determined by business purpose.

NetSuite-to-Acumatica Data Mapping

Extraction produces source data. Mapping determines how that data behaves in Acumatica.

A mapping specification should identify the source object, source field, source identifier, target object, target field, transformation rule, default values, validation, error handling, and reconciliation method.

NetSuite Concept Possible Acumatica Target Design Consideration
Subsidiary Company / Branch Legal entity, currency, tax, reporting, and intercompany structure
Location Branch / Warehouse / Warehouse Location NetSuite locations may represent several different business concepts
Department / Class Subaccount Segment / Reporting Dimension Reporting should be redesigned instead of blindly copying source dimensions
Customer Customer Classes, terms, contacts, addresses, taxes, and external IDs
Vendor Vendor Terms, currencies, payments, taxes, and contacts
Inventory Item Stock Item Item classes, UOM, costing, warehouses, lot and serial rules
Saved Search Generic Inquiry / Report / Dashboard / BI Rebuild according to purpose rather than screen-for-screen
SuiteScript Standard Functionality / Workflow / API / Customization Preserve business logic rather than source code

NetSuite Subsidiaries to Acumatica Companies and Branches

Multi-entity migration is one of the most important architectural areas.

A NetSuite OneWorld environment may contain subsidiaries with different base currencies, tax registrations, accounting structures, locations, intercompany relationships, user permissions, and reporting requirements.

Legal Entity Boundaries

The project must determine which subsidiaries represent actual legal entities and which exist primarily for operational or reporting purposes.

Branch Design

A source location may become:

  • an Acumatica branch;
  • a warehouse;
  • a warehouse location;
  • a reporting dimension;
  • an archived concept.

Intercompany Transactions

The migration must identify:

  • due-to and due-from accounts;
  • intercompany customers and vendors;
  • eliminations;
  • cross-entity inventory movement;
  • shared services;
  • consolidation requirements.

Currency

The design should address base currencies, transaction currencies, exchange rates, historical rates, revaluation, and consolidation.

NetSuite Financial Data Migration to Acumatica

Financial migration is the foundation of the ERP replacement.

The company must be able to prove that Acumatica agrees with the approved NetSuite financial position at cutover.

Chart of Accounts

Review:

  • active accounts;
  • inactive accounts;
  • control accounts;
  • bank accounts;
  • retained earnings;
  • intercompany accounts;
  • segment-based reporting;
  • duplicate or obsolete accounts.

The chart should not necessarily be copied one-for-one.

Acumatica subaccounts and reporting dimensions may provide a cleaner reporting structure.

Opening Balances

Opening balances may be loaded by account, subaccount, branch, currency, and other approved dimensions.

Historical General Ledger

The company should choose between full transaction history, summarized historical balances, selected comparative periods, or opening balances only.

Financial Reconciliation

At minimum compare:

  • trial balance;
  • balance sheet;
  • income statement;
  • cash;
  • AR control accounts;
  • AP control accounts;
  • inventory accounts;
  • fixed assets;
  • intercompany balances;
  • retained earnings.

NetSuite Customer and Vendor Migration

Master data migration should improve quality rather than simply preserve every source record.

Customers

  • customer ID;
  • company name;
  • contacts;
  • billing addresses;
  • shipping addresses;
  • terms;
  • credit limits;
  • tax settings;
  • currency;
  • salesperson;
  • pricing;
  • hierarchy;
  • external IDs;
  • marketplace identifiers;
  • custom attributes.

Vendors

  • vendor ID;
  • name;
  • contacts;
  • addresses;
  • terms;
  • currency;
  • tax identifiers;
  • payment information;
  • item relationships;
  • custom attributes;
  • external IDs.

Duplicate Management

Duplicates may exist because of subsidiaries, currencies, locations, integrations, historical imports, and separate sales or billing relationships.

They should not be merged automatically without business review.

NetSuite Inventory Migration to Acumatica

Inventory is one of the most complex areas of ERP migration.

A successful transition must align item master data, physical quantities, financial value, warehouse structure, open demand, open supply, and external channel availability.

Item Types

  • inventory items;
  • non-inventory items;
  • service items;
  • assemblies;
  • kits;
  • matrix parents;
  • matrix children;
  • lot-numbered items;
  • serialized items.

Location Mapping

NetSuite locations may map to Acumatica branches, warehouses, warehouse locations, or reporting dimensions.

Opening Inventory

The migration may need:

  • on-hand quantity;
  • available quantity;
  • allocated quantity;
  • lot balances;
  • serial numbers;
  • warehouse locations;
  • inventory status;
  • cost layers where applicable.

Inventory Reconciliation

Compare:

  • NetSuite inventory;
  • WMS inventory;
  • physical inventory;
  • eCommerce availability;
  • inventory valuation;
  • general ledger inventory accounts.

Migrating Open AR, AP, Sales Orders, and Purchase Orders

Open documents are often more important than closed historical transactions because the business must continue processing them immediately after go-live.

Accounts Receivable

  • open invoices;
  • credit memos;
  • unapplied payments;
  • customer deposits;
  • remaining balances;
  • due dates;
  • currency;
  • payment applications.

Accounts Payable

  • vendor bills;
  • vendor credits;
  • prepayments;
  • unapplied payments;
  • remaining balances;
  • due dates;
  • currency.

Sales Orders

  • customer;
  • items;
  • ordered quantities;
  • shipped quantities;
  • warehouse;
  • prices;
  • discounts;
  • taxes;
  • shipping method;
  • customer PO number;
  • channel identifiers;
  • fulfillment state.

Partially fulfilled orders require special attention.

Purchase Orders

  • vendor;
  • items;
  • ordered quantity;
  • received quantity;
  • warehouse;
  • cost;
  • expected date;
  • currency;
  • related receipts and bills.

NetSuite Historical Data Migration

One of the biggest migration decisions is how much history belongs in Acumatica.

There are several valid strategies.

Full Transaction-Level History

Advantages:

  • users research history in one ERP;
  • comparative reporting is easier;
  • less dependency on the legacy account;
  • customer and vendor history remains directly accessible.

Disadvantages:

  • higher cost;
  • longer testing;
  • more data transformation;
  • more reconciliation;
  • higher risk of importing obsolete structures.

Limited Detailed History

The company migrates a selected time range such as the current fiscal year plus comparative periods.

Summary History

Detailed transactions stay archived while Acumatica receives summarized historical balances.

Opening Balances and Open Documents Only

Acumatica begins cleanly at cutover while legacy information remains accessible through controlled archival methods.

How to Choose

Consider:

  • audit requirements;
  • tax retention;
  • customer service;
  • warranty requirements;
  • traceability;
  • project history;
  • comparative reporting;
  • legacy system cost;
  • migration budget;
  • data quality.

NetSuite Custom Records Migration

NetSuite custom records may represent critical business processes, but a custom record should not automatically become a custom Acumatica object.

First identify why it exists.

A custom record may be:

  • a genuine business entity;
  • an extension of a standard record;
  • an integration staging object;
  • a reporting workaround;
  • a process Acumatica already supports;
  • an obsolete customization.

The migration process should:

  1. Inventory the custom record.
  2. Document fields and relationships.
  3. Identify scripts and workflows that use it.
  4. Identify saved searches and integrations that depend on it.
  5. Define the business requirement.
  6. Select the appropriate Acumatica design.
  7. Migrate data only after the target structure is approved.

NetSuite SuiteScript Migration to Acumatica

SuiteScript is NetSuite’s JavaScript-based customization framework.

A mature account may contain:

  • user event scripts;
  • client scripts;
  • scheduled scripts;
  • Map/Reduce scripts;
  • RESTlets;
  • Suitelets;
  • workflow action scripts;
  • mass update scripts;
  • custom modules.

These scripts cannot simply be copied into Acumatica.

The platforms use different data models, APIs, events, security models, UI frameworks, and customization architectures.

A SuiteScript to Acumatica migration should classify each script by business purpose.

Document:

  • what triggers it;
  • which records it reads;
  • which records it changes;
  • which external systems it calls;
  • how errors are handled;
  • how frequently it runs;
  • who depends on it;
  • whether the requirement still exists.

A SuiteScript may be replaced by:

  • standard Acumatica functionality;
  • configuration;
  • workflow automation;
  • business events;
  • import/export scenarios;
  • REST APIs;
  • webhooks;
  • a scheduled integration service;
  • a BizTech connector;
  • custom Acumatica development.

Preserve business logic, not NetSuite source code.

NetSuite Workflow Migration

NetSuite workflows may control approvals, status changes, field updates, notifications, record creation, validation, routing, and business rules.

For each workflow, document:

  • record type;
  • trigger;
  • states;
  • transitions;
  • conditions;
  • actions;
  • approvers;
  • notifications;
  • exceptions;
  • integration dependencies.

Acumatica may support the requirement through standard workflow configuration, approval maps, business events, notifications, or custom logic.

The goal is to preserve the correct business control, not recreate SuiteFlow visually.

Migrating NetSuite Integrations to Acumatica

Integration architecture can be one of the largest components of a NetSuite replacement.

A mature environment may connect NetSuite with:

  • Shopify;
  • WooCommerce;
  • Amazon;
  • Magento;
  • BigCommerce;
  • Salesforce;
  • payment gateways;
  • banks;
  • tax services;
  • EDI providers;
  • warehouse systems;
  • shipping systems;
  • 3PLs;
  • planning software;
  • BI tools;
  • custom applications.

Create an integration inventory containing the system, owner, authentication method, entities, direction, frequency, volume, error handling, monitoring, NetSuite dependencies, and target Acumatica architecture.

Existing BizTech Acumatica Connectors

BizTech already develops solutions for many platforms commonly found around NetSuite.

This can significantly reduce the amount of migration code that needs to be built from zero.

Do Not Rebuild NetSuite Inside Acumatica

This is one of the most important principles in the entire migration.

Users naturally ask for familiar behavior.

They may want the same screens, field names, approval steps, reports, scripts, and workarounds.

Some requirements should remain. Others exist only because the old ERP required them.

A stronger migration sequence is:

  1. Standard Acumatica functionality.
  2. Configuration and workflow.
  3. Existing BizTech or Acumatica ecosystem solution.
  4. Integration with a specialized external platform.
  5. Custom development only when genuinely required.

This approach can reduce implementation cost, technical debt, custom code, upgrade risk, support complexity, and training burden.

The purpose of leaving NetSuite should not be to build a NetSuite-shaped Acumatica. The purpose is to create a better ERP operating model.

NetSuite to Acumatica Migration Process

Phase 1: Migration Discovery

Review the business objectives, reasons for leaving NetSuite, modules, subsidiaries, locations, currencies, inventory, transactions, integrations, SuiteApps, custom records, SuiteScripts, workflows, saved searches, reports, users, and contract timing.

Phase 2: Acumatica Fit-Gap Analysis

Classify each requirement as:

  • standard functionality;
  • configuration;
  • integration;
  • existing BizTech product;
  • custom development;
  • process redesign;
  • retirement.

Phase 3: Target Architecture

Design companies, branches, financial structures, warehouses, customers, vendors, security, workflows, integrations, reporting, historical data strategy, and deployment.

Phase 4: Extraction Design

Define the source and extraction method for every dataset.

Phase 5: Data Cleansing

Standardize, deduplicate, validate, and reconcile source data.

Phase 6: Acumatica Configuration

Configure the approved ERP applications and business structures.

Phase 7: Integrations and Customization

Develop only requirements approved through the fit-gap process.

Phase 8: Test Migration

Perform a realistic migration rehearsal using representative production data.

Phase 9: Financial and Operational Reconciliation

Compare Acumatica against approved NetSuite control reports and operational sources.

Phase 10: User Acceptance Testing

Users test complete business scenarios from beginning to end.

Phase 11: Training and Change Management

Train users by role and explain how the new Acumatica processes differ from the old NetSuite environment.

Phase 12: Final Cutover

Freeze NetSuite transactions, perform final extraction, migrate production data, reconcile balances, activate integrations, and approve production use.

Phase 13: Stabilization

Monitor users, integrations, reports, system performance, and exceptions after go-live.

NetSuite to Acumatica Migration Cost

There is no universal fixed migration cost.

Major cost drivers include:

  • number of subsidiaries;
  • number of locations;
  • transaction volume;
  • historical data;
  • custom records;
  • custom segments;
  • SuiteScripts;
  • workflows;
  • saved searches;
  • SuiteApps;
  • integrations;
  • industry requirements;
  • data quality;
  • reporting;
  • training;
  • cutover complexity.
Cost Category Examples
Acumatica Software Applications, resources, storage, and deployment
Discovery NetSuite audit, fit-gap analysis, architecture
Data Migration Extraction, cleansing, mapping, imports, reconciliation
Customization Migration Custom records, fields, SuiteScript, workflows
Integration Migration Commerce, payments, WMS, CRM, EDI, tax, shipping
Reporting Saved searches, reports, dashboards, BI
Testing and Training Migration tests, UAT, user education
Go-Live and Support Cutover, stabilization, monitoring, optimization

What Reduces Migration Cost?

  • clean data;
  • limited historical scope;
  • strong process owners;
  • retiring obsolete scripts;
  • using standard Acumatica workflows;
  • using existing BizTech connectors;
  • clear reporting requirements;
  • fast decisions;
  • phased implementation.

What Increases Migration Cost?

  • many subsidiaries;
  • complex intercompany processes;
  • full detailed history;
  • large custom-record footprint;
  • extensive SuiteScript;
  • hundreds of saved searches;
  • many integrations;
  • poor source data;
  • compressed timeline;
  • unclear scope.

NetSuite to Acumatica Migration Timeline

Migration duration can vary significantly.

Focused projects can be measured in weeks, while broader ERP transformations involving multiple entities, historical data, customizations, integrations, and complex operational processes may require several months.

Timeline is affected by:

  • subsidiaries;
  • data volume;
  • history;
  • modules;
  • customization;
  • integrations;
  • user availability;
  • testing;
  • training;
  • renewal timing.

The project should use milestones rather than relying on one unsupported universal duration.

When Should You Start Planning Before NetSuite Renewal?

Contract timing can materially affect migration risk.

12+ Months Before Renewal

Ideal for ERP research, Acumatica demonstrations, requirements workshops, contract review, customization inventory, integration inventory, and budget planning.

9–12 Months Before Renewal

Begin fit-gap analysis, data audit, target architecture, implementation partner selection, and detailed migration estimates.

6–9 Months Before Renewal

For many midmarket projects, implementation should already be active.

3–6 Months Before Renewal

A migration may still be achievable, but scope discipline becomes critical.

The company may need:

  • phased rollout;
  • temporary legacy access;
  • limited historical migration;
  • priority integrations;
  • a transition period.

Less Than 3 Months

Do not force an unsafe cutover only to avoid renewal.

Assess whether a controlled migration is realistic or whether temporary overlap is safer.

NetSuite to Acumatica Migration for Manufacturing

Manufacturers may need to migrate:

  • assemblies;
  • BOMs;
  • routing;
  • work centers;
  • production orders;
  • MRP;
  • WIP;
  • labor;
  • overhead;
  • lot and serial tracking;
  • quality integrations;
  • manufacturing costing.

Manufacturing data usually requires more design than a direct record import.

NetSuite to Acumatica Migration for Distribution

Distribution projects may include:

  • multi-warehouse inventory;
  • sales orders;
  • purchase orders;
  • replenishment;
  • customer pricing;
  • returns;
  • EDI;
  • shipping;
  • marketplaces;
  • inventory analytics.

NetSuite to Acumatica Migration for eCommerce

Commerce migrations are highly integration-dependent.

The project may involve:

  • Shopify;
  • Amazon;
  • WooCommerce;
  • Magento;
  • BigCommerce;
  • payments;
  • warehouses;
  • shipping;
  • returns;
  • refunds;
  • channel profitability.

BizTech’s connector portfolio can significantly reduce the amount of custom development required.

NetSuite to Acumatica Migration for Multi-Entity Companies

Multi-entity migration requires special attention to:

  • subsidiaries;
  • companies;
  • branches;
  • intercompany accounting;
  • currencies;
  • taxes;
  • shared customers;
  • shared vendors;
  • security;
  • consolidation;
  • entity-specific integrations.

Common NetSuite-to-Acumatica Migration Risks

Risk 1: Treating CSV Export as a Complete Backup

Additional extraction methods may be required for a complete migration.

Risk 2: Rebuilding Custom Code Before Understanding It

SuiteScript should be analyzed by business purpose before development starts.

Risk 3: Missing Integration Dependencies

A saved search or custom field may be used by an integration even if end users do not recognize it as important.

Risk 4: Losing Cross-System IDs

External systems may store NetSuite internal IDs. Cross-reference planning is essential.

Risk 5: Migrating Too Much History

Historical migration can dominate cost and testing without providing equivalent business value.

Risk 6: Ignoring Attachments

Files may be operationally, legally, or financially important.

Risk 7: Rebuilding Every Saved Search

Many saved searches can be replaced with standard Acumatica inquiries, dashboards, reports, or alerts.

Risk 8: Underestimating User Acceptance Testing

Users must test complete processes rather than individual screens.

Risk 9: Rushing Cutover Around Renewal

Temporary overlap may be safer than an uncontrolled ERP launch.

Risk 10: No Post-Go-Live Monitoring

Real production volume often reveals exceptions that did not appear during testing.

Why Work with BizTech for NetSuite to Acumatica Migration?

BizTech is an Acumatica Gold Partner combining ERP implementation expertise with integration and custom product development.

This combination is particularly valuable during a NetSuite replacement.

A company may need:

  • ERP discovery;
  • data extraction;
  • financial migration;
  • inventory migration;
  • customization analysis;
  • integration redesign;
  • Acumatica implementation;
  • custom development;
  • reporting;
  • testing;
  • training;
  • cutover;
  • support.

BizTech can coordinate these areas as one migration program.

Custom Acumatica Development

BizTech develops custom APIs, workflows, connectors, screens, business logic, and Acumatica enhancements.

Existing Connector Portfolio

BizTech solutions include:

  • Amazon;
  • Shopify;
  • WooCommerce;
  • Magento;
  • ShipHero;
  • ShipStation;
  • DSCO;
  • CommerceHub;
  • EZCom;
  • Salesforce;
  • ServiceTitan;
  • PayPal;
  • Kit Processing;
  • Consignment Processing;
  • Gift Card Processing;
  • custom integrations.

Ongoing Support

BizTech can provide integration monitoring, issue resolution, performance optimization, feature updates, customization maintenance, and ongoing Acumatica support.

Final NetSuite to Acumatica Migration Checklist

Business Case

  • Reasons for replacing NetSuite are documented.
  • Success metrics are defined.
  • Executive sponsorship is confirmed.
  • Contract dates are documented.
  • Process owners are assigned.

NetSuite Inventory

  • Modules are documented.
  • Subsidiaries are documented.
  • Locations are documented.
  • Currencies are documented.
  • Custom segments are documented.
  • Custom records are inventoried.
  • Custom fields are inventoried.
  • SuiteScripts are inventoried.
  • Workflows are inventoried.
  • Saved searches are inventoried.
  • SuiteApps are inventoried.
  • Integrations are inventoried.
  • Files and attachments are assessed.

Acumatica Target Design

  • Companies and branches are approved.
  • Chart of accounts is approved.
  • Subaccounts are approved.
  • Customer and vendor classes are approved.
  • Item classes are approved.
  • Warehouses are approved.
  • Order types are approved.
  • Security roles are approved.
  • Workflow design is approved.
  • Integration architecture is approved.

Data Migration

  • Extraction methods are documented.
  • Saved searches are tested.
  • Data mapping is approved.
  • Duplicates are resolved.
  • Inactive records are reviewed.
  • Historical strategy is approved.
  • AR reconciles.
  • AP reconciles.
  • Inventory reconciles.
  • Trial balance reconciles.
  • Open documents are validated.
  • Test migration is approved.

Integrations

  • Every integration has an owner.
  • Authentication is tested.
  • Cross-references are defined.
  • Error handling is tested.
  • Retry logic is tested.
  • Monitoring is enabled.
  • Orders are tested.
  • Inventory synchronization is tested.
  • Payments are tested.
  • Fulfillment is tested.
  • Returns and refunds are tested.

Cutover

  • NetSuite transaction freeze is scheduled.
  • Final exports are scheduled.
  • Backups and archives are available.
  • Production migration is rehearsed.
  • Reconciliation responsibilities are assigned.
  • Go-live criteria are documented.
  • Contingency plans are documented.
  • Post-go-live support is scheduled.

Final Conclusion: Moving from NetSuite to Acumatica

Replacing NetSuite is a significant ERP decision.

The company may be moving away from an environment that has accumulated years of data, customizations, integrations, reports, and institutional knowledge.

That makes migration complex, but it also creates an opportunity.

A NetSuite replacement allows the business to ask questions that may not have been asked for years:

  • Do we still need this customization?
  • Should this saved search become a dashboard?
  • Should this SuiteScript become a standard workflow?
  • Do we need all historical data in the production ERP?
  • Should this external application remain?
  • Can our eCommerce integrations be simplified?
  • Can more employees work directly in ERP?
  • Can we reduce dependency on specialized development?
  • Can reporting become more real-time?
  • Can our ERP support the next stage of growth?

Acumatica provides a strong target platform for organizations that want modern cloud ERP, open architecture, industry-specific functionality, flexible integrations, customer-focused product direction, and growth-friendly user access.

But the platform alone does not determine migration success.

The project requires discovery, data extraction, mapping, financial reconciliation, integration architecture, customization redesign, testing, training, cutover management, and post-go-live support.

As an Acumatica Gold Partner, BizTech helps companies manage this complete transition.

NetSuite is the source. Acumatica is the new platform. BizTech helps build the migration path between them.

FAQ: NetSuite to Acumatica Migration

Can NetSuite data be migrated to Acumatica?

Yes. Financial data, customers, vendors, inventory, open transactions, subsidiaries, locations, projects, selected history, custom-field data, and many other records can be migrated. Exact scope depends on the NetSuite configuration and target Acumatica design.

How do you export NetSuite data for migration?

NetSuite supports several extraction methods including CSV exports, saved searches, reports, analytics connections, web services, and scripted extraction. Complex migrations often use several methods.

Can NetSuite saved searches be migrated to Acumatica?

Their business purpose can be migrated, but the saved search itself is not imported directly. It may be rebuilt as an Acumatica Generic Inquiry, report, dashboard, business event, workflow condition, integration endpoint, or BI dataset.

Can SuiteScript be migrated to Acumatica?

SuiteScript code cannot simply be copied because NetSuite and Acumatica use different APIs and customization frameworks. The business logic should be analyzed and reimplemented using standard Acumatica functionality, workflows, APIs, webhooks, integrations, or custom development.

Can NetSuite custom records be migrated?

Yes. The underlying data can often be migrated, but a target Acumatica data model must be designed first. Some custom records may become standard functionality, fields, attributes, custom tables, integrations, or may be retired.

How long does NetSuite to Acumatica migration take?

There is no universal duration. Project length depends on subsidiaries, data volume, customizations, integrations, historical requirements, testing, and scope. Focused migrations may be measured in weeks, while broader ERP transformations may require several months.

How much does NetSuite to Acumatica migration cost?

Cost depends on Acumatica applications, data volume, historical migration, subsidiaries, custom records, SuiteScripts, workflows, integrations, reporting, testing, training, and support. Structured discovery is required for a reliable estimate.

When should we begin planning before NetSuite renewal?

Begin as early as possible. Organizations with more time have more flexibility for discovery, data cleanup, integration development, testing, and controlled cutover.

Can several NetSuite subsidiaries be migrated to Acumatica?

Yes. Subsidiaries can be mapped to Acumatica companies and branches depending on legal, tax, currency, security, financial, and reporting requirements.

Can NetSuite inventory and warehouses be migrated?

Yes. Items, quantities, costs, lots, serials, locations, open demand, open supply, and warehouse relationships can be migrated when source data is available and reconciled.

Can open AR and AP be migrated?

Yes. Open invoices, vendor bills, credits, payments, deposits, remaining balances, due dates, and applications can be migrated and reconciled in Acumatica.

Can BizTech rebuild our NetSuite integrations in Acumatica?

Yes. BizTech develops custom Acumatica integrations and also provides existing solutions for Amazon, Shopify, WooCommerce, Magento, PayPal, ShipHero, ShipStation, DSCO, CommerceHub, Salesforce, ServiceTitan, EDI, and other systems.

Why choose BizTech for a NetSuite replacement?

BizTech is an Acumatica Gold Partner combining ERP implementation, data migration, custom development, proprietary connectors, integration architecture, reporting, testing, training, and post-go-live support.

The post NetSuite to Acumatica Migration Guide 2026: Why Companies Switch and How to Migrate Successfully appeared first on Biz-Tech Services.

]]> How Amazon FBA and FBM Data Flows into Acumatica ERP https://biz-techservices.com/archives/10268 Fri, 07 Aug 2026 06:07:31 +0000 https://biz-techservices.com/?p=10268 How Amazon FBA and FBM Data Flows into Acumatica ERP Amazon order data flows into Acumatica ERP through the Biz-Tech […]

The post How Amazon FBA and FBM Data Flows into Acumatica ERP appeared first on Biz-Tech Services.

]]> How Amazon FBA and FBM Data Flows into Acumatica ERP

Amazon order data flows into Acumatica ERP through the Biz-Tech Services Amazon Connector, which retrieves orders from Amazon into an intermediate server, imports the selected orders into Acumatica as sales orders or invoices, and then sends purchase order acknowledgements, fulfillment events, refunds, and inventory quantities back to Amazon. The connection is never direct. Every request travels through an intermediate server controlled by Biz-Tech Services, and the settings that govern that connection live on the Amazon Stores screen in Acumatica. Once those settings are in place, the Biz-Tech Services Acumatica Amazon connector handles two distinct fulfillment channels: Fulfillment by Merchant, or FBM, where your business ships the goods, and Fulfillment by Amazon, or FBA, where Amazon ships from its own fulfillment centers.

Those two channels take different paths through Acumatica, and understanding the difference is the key to using the Biz-Tech Services Acumatica Amazon connector well. FBM orders become sales orders that your warehouse picks, packs, ships, and invoices, with acknowledgements and fulfillment documents flowing back at each step. FBA records arrive as transfer orders, purchase receipts, and invoices, because the movement being recorded is a transfer of your stock into Amazon inventory rather than a shipment to a shopper. This article traces the whole path in the order the records travel, names the screens, tabs, buttons, and fields involved at each stage, and points out where users should look when something does not land as expected.

What the Amazon Connector for Acumatica Does

The Amazon Connector is an Acumatica ERP customization from Biz-Tech Services, Inc. that links Amazon, the e-commerce platform, with Acumatica enterprise resource planning. It is delivered as a customization project and must be installed on an Acumatica system carrying one of the supported licenses, PCSR, PERP, or SAAS.

The documented capabilities cover both directions of travel. Inbound, the Biz-Tech Services Acumatica Amazon connector imports Amazon orders as either sales order or invoice document types, creates the customer on the fly when that customer does not yet exist in Acumatica, imports sales tax, and imports payment information. Outbound, it sends purchase order acknowledgements, sends fulfillment documents when shipments are confirmed, and sends inventory status documents so Amazon sees the quantity your business actually has available. A cross-reference layer sits between the two systems and matches items, payments, and Ship Via values so that Amazon terminology resolves to Acumatica records instead of failing.

Several of the outbound actions can be run three ways: from the Actions menu on a single Sales Orders document, from a processing screen where many records are selected and pushed at once, or automatically. Acknowledgements can be sent automatically with a Success status, and fulfillment documents can be sent automatically when an invoice is prepared. That mix matters because a business running a handful of orders a day works differently from one running hundreds, and the same configuration supports both.

The Amazon Data Flow at a Glance

Before looking at individual screens, here is the path records travel through the Amazon Connector from setup to settlement of the last refund:

  • Credentials are entered and tested on the Connection Settings tab of the Amazon Store screen, which confirms Acumatica can reach the Biz-Tech server that fronts Amazon.
  • The rest of the Amazon Store screen defines behavior: FBM Settings and FBA settings tabs, plus Cross-Reference, Warehouse Details, Inventory Details, Carriers Code, Cancel Reasons, and Adjustment Reasons tabs.
  • For FBM, the Get Orders button on the Import Amazon Orders screen pulls Amazon orders into a grid, filtered by Start Date and End Date, where they can be reviewed before anything is committed.
  • The Import or Import All button turns the selected Amazon orders into Acumatica documents, applying the customer, item, tax, payment, and cross-reference rules configured on the store.
  • Outbound acknowledgement is sent from the Sales Orders Actions menu or from the Export Amazon PO Acknowledgement processing screen, which pushes the acknowledgement through the Biz-Tech server to Amazon.
  • Fulfillment follows the standard Acumatica chain, Create Shipment, Confirm Shipment, Prepare Invoice, and Release, with Prepare Invoice fulfilling the order in Amazon.
  • For FBA, Import FBA Shipments creates transfer orders and purchase receipts as stock moves into Amazon fulfillment centers, while Import FBA Orders brings in the resulting FBA sales as invoices.
  • Refunds travel back through Import Amazon Refunded Orders, which produces a customer refund payment or a credit memo depending on how far the original order had progressed.
  • Inventory quantities travel outward from the Export Amazon Inventory Quantity screen, summed across the warehouses listed on the Warehouse Details tab.

FBA and FBM: Two Fulfillment Paths, One Amazon Connector

Fulfillment by Amazon is a service Amazon provides so sellers can streamline logistics and order fulfillment. Under FBA, sellers store their products in Amazon fulfillment centers, and Amazon handles the storage, packing, shipping, and customer service for those items. Fulfillment by Merchant is the opposite arrangement: the seller keeps the stock and ships the order. Because the physical goods behave differently, the Acumatica documents behave differently too, and the Biz-Tech Services Acumatica Amazon integrator keeps the two channels on separate tabs and separate processing screens.

The practical consequence is that FBM is an order-to-cash flow and FBA is partly an inventory-transfer flow. An FBM order becomes a sales order of the type configured on the FBM Settings tab, and your business creates the shipment, enters the tracking number, and confirms it. An FBA record set arrives in pieces: shipments of your stock into Amazon become transfer orders, deliveries become purchase receipts in the destination warehouse, and the actual FBA sales come in as invoices. FBA settings therefore include warehouse mapping and a Destination Order Type that has to be a Transfer order type, which has no equivalent on the FBM side.

Both channels can be reviewed together. The FBM and FBA Orders screen shows both kinds of order in one place, and the distinction between them is indicated by the Fulfillment channel field. When users are not sure which path a given order took through Acumatica, that field is the answer.

Stage One: Installing the Package and Connecting Acumatica to Amazon

The Biz-Tech Services Acumatica Amazon integration arrives as a customization project, a set of changes and additional files used to modify the Acumatica ERP application. Administrators import the deployment package, open it for editing in the Customization Project Editor if needed, validate it, and publish it for one tenant or several. Publishing uploads the package, creates the corresponding customization project, and saves it in the database. None of the Biz-Tech Services Acumatica Amazon connector screens exist until that happens.

What the Amazon Store screen identifies

The Amazon Store screen is the anchor record for everything else. Store Code is a lookup field that indicates the corresponding store, and Description describes it. The data on the General tab is provided automatically for the Store Code entered. When the Default Store checkbox is selected, that store appears automatically whenever a user opens a processing screen or a store screen and clicks into the Store code field. On an installation with a single marketplace this saves a click on every process; on an installation with several stores it prevents the more expensive mistake of running a process against the wrong marketplace.

Which credentials the Connection Settings tab holds

The Connection Settings tab uses the information specified on it to test whether Acumatica can connect to the Acumatica to Biz-Tech server. Get a successful test here before touching any other tab, because a failed import caused by a bad credential looks very similar to one caused by a bad mapping.

The fields on this tab are the OAuth and Amazon identifiers the intermediate server needs. Client ID is the identifier associated with an application that assists with client and server OAuth 2.0 authentication. Client secret is a secret known only to the application and the authorization server, and functions as the application own password. A refresh token is a special key that lets a client retrieve new access tokens without requiring the user to perform a complete login, which is what allows scheduled processes to run unattended. Marketplace is the store location, and AWS Regions are the physical locations where Amazon clusters data centers for application and service delivery in AWS Availability Zones.

The remaining values complete the picture. Consumer Key is the API key a service provider issues to a consumer, and it identifies that consumer. Consumer Secret is the consumer password, used along with the consumer key to request authorization to a user resources. External System Store ID is an identifier used to track data in relation to external systems integrated with the Amazon platform. Seller ID and MWS Auth Token are generated when the new developer authorization process is passed. If any of these are wrong, nothing downstream works.

Stage Two: FBM Settings That Govern How Amazon Orders Import

The FBM Settings tab on the Amazon Store screen decides what an imported Amazon order looks like in Acumatica. Import Amazon Orders specifies where to import the Amazon orders in the Acumatica system, and Order Type is the default type of order the Biz-Tech Services Acumatica Amazon integration creates. The Last Imported Order Date field shows the date the latest order was imported, which is the quickest sanity check that the flow is still running. When the Send Email Notifications for Errors checkbox is selected, the Biz-Tech Services Acumatica Amazon connector sends email notifications listing the Order IDs that hit errors, so nobody has to sit watching a grid.

How customer records are created from Amazon orders

When the Import Customer checkbox is selected, the Biz-Tech Services Acumatica Amazon integration imports the customer information from Amazon into a new customer record in Acumatica. When it is not selected, orders are imported against the default customer instead. This is a real business decision: importing customers gives your business a per-shopper record and history, while a single default customer keeps the customer ledger compact when shoppers are not accounts you intend to manage.

Two checkboxes control addresses. Override Ship Address Information from Amazon Order imports the address of the location the order is going to be shipped to from Amazon. Override Bill Address Information from Amazon Order imports the address information of whoever will pay the order bill from Amazon. Where the Amazon-supplied address must win over whatever is stored on the Acumatica customer, these are the settings that make it win.

How Amazon items are matched or created on import

The Import Item checkbox tells the Biz-Tech Services Acumatica Amazon integrator to import new product information from Amazon into Acumatica when that product does not yet exist in the Acumatica system. If the checkbox is not selected and an unknown item arrives, an error will occur during integration. That single checkbox is behind a large share of first-week import failures, so it is worth checking first when imports stop.

There is a documented nuance about descriptions. If the item already exists on the Stock Items screen, the Biz-Tech Services Acumatica Amazon connector does not update its description, but it does set the Amazon item title as the description in the Line description on the Sales Orders screen. The Acumatica master record keeps your naming, and the order line carries the marketplace wording that a shopper would quote.

Warehouse ID is the default warehouse set on imported orders, and UOM, the unit of measure, is used to quantify the inventory items. When the Insert Item in Inventory Details Tab checkbox is selected, items are retrieved into the Inventory Details tab of the Amazon Store screen while orders are being imported, which builds the mapping table as a side effect of normal trading rather than as a separate data-entry project.

Tax and payment defaults applied during import

Three tax fields sit on the same tab. Taxable Category is used to create or edit the tax categories applied to products. Customer Tax Zone is the combined set of effective taxes for a zone, defined according to the locations of vendors or customers. Tax ID is the client tax identifier. Because the Biz-Tech Services Acumatica Amazon connector can import sales tax from Amazon, these defaults are what the imported tax lands against, and a missing tax zone is a common reason an otherwise valid Amazon order will not post.

Under Payment Options, Payment Method is the default payment method set for the new customer records generated in Acumatica from the Amazon orders. Cross-Reference options is the setting that selects which entities should be matched between Amazon and Acumatica during the transition, and it directly controls the next tab.

Cross-References, Warehouses, Carriers, and Reason Codes

Between the credentials and the processing screens sits a set of tabs whose only job is translation. They are unglamorous and they are where most integration problems are actually solved.

The Cross-Reference tab

On the Cross-Reference tab, the Field column selects the entity whose Amazon and Acumatica values should be matched, and only the entities selected under Cross-Reference Options appear in that drop-down. Amazon Value then specifies which Amazon value must match which Acumatica Value. The documented example to verify afterwards is Ship Via: after the Amazon order import process, the Ship Via value should be visible in the Delivery Settings area of the Shipping tab on the Sales Orders screen. If it is blank there, the cross-reference is the place to look, not the order.

The Warehouse Details tab

The Warehouse Details tab is where your business adds the warehouses that need to be in sync with Amazon. Two behaviors follow from it. If several warehouses are selected on this screen, the exported item quantity is the sum of quantities across those selected warehouses, so Amazon sees pooled availability rather than a single site. And depending on the drop-down value selected, On hand, Available, or Available for Shipment, that is the quantity basis synced from Acumatica to Amazon. Choosing Available for Shipment rather than On hand is how your business avoids advertising stock that is already allocated.

The Inventory Details tab and SKU mapping

To upload a new SKU for an Amazon item, the mapping is created on the Inventory Details tab of the Amazon Store screen. If Import Item is checked on the import settings and an order is imported, the connector generates an Acumatica Inventory ID based on the SKU. To update the SKU afterwards, change the SKU for the existing item on the Inventory Details tab and import again, and no new item is created in Acumatica. That is the documented way to correct a mapping without leaving duplicate inventory IDs behind.

One pricing rule is worth committing to memory: during order import the Biz-Tech Services Acumatica Amazon connector takes the Amazon item price rather than the mapped Acumatica item price. The Amazon order is the commercial record of what the shopper paid, so Acumatica records that number rather than your list price.

Four buttons populate this tab. Get Product by ASIN displays the Amazon item in Inventory Details by its ASIN. Get Product by SELLERSKU does the same by SKU. Load FBA Products loads and displays all Amazon products in the store. Sync From Amazon takes a loaded FBA item and creates that item in Acumatica via the product SKU, which is the fastest way to seed Acumatica with an existing Amazon catalog rather than typing it.

Carriers Code, Cancel Reasons, and Adjustment Reasons

The Carriers Code tab matches Amazon carrier details to the Acumatica Ship Via carrier. The Cancel Reasons tab holds the order cancel reasons, and a cancellation reason must be selected while cancelling orders, so an empty tab blocks cancellations. The Adjustment Reasons tab is populated the same way and its values are required for refunding Amazon orders. Both reason lists can be imported or exported as an Excel file, which is the practical way to load them once and reuse them across tenants.

Inbound: How Amazon FBM Orders Become Acumatica Documents

The Import Amazon Orders screen is the inbound gate for FBM. The user indicates the Store Code, and the screen retrieves data for that store: it pulls as many orders into Acumatica as exist in the selected period and displays all of them in the table, so nothing is committed on retrieval alone.

Retrieving Amazon orders with Get Orders

Step one is clicking the Get Orders button to retrieve orders from Amazon. After the button is clicked a timer indicates the elapsed time until the process is complete, and a user can cancel the retrieval by clicking the loading icon next to the timer. The Start Date and End Date fields filter the data retrieval, which is how your business avoids dragging months of history back on a routine run. Step two is reviewing the retrieved orders to decide which ones need to be imported.

Reviewing an order before importing it

Clicking the Order Number opens the corresponding order in a pop-up window, and the most important information is shown on the Amazon Orders screen. This is also the first place errors surface: if an error appears while importing a corresponding order, the error message is displayed on this screen and explains what should be fixed and in which system. That last part matters, because roughly half of import problems are Amazon-side data and half are missing Acumatica configuration.

Running the import

Step four is selecting the orders that require import. Step five is clicking the Import button to begin the import process, or the Import All button to import every order in the grid. After the Import button is pressed, unselected orders are filtered off the screen so the grid shows only what is being worked. A user can cancel the process of importing orders by clicking close.

If there is an error while processing an order, the error displays on the grid line corresponding to that order, and a user should hover the cursor over the red cross to see additional information about it. For deeper detail, a user can open Tools and then Trace.

Outbound: Sending Amazon PO Acknowledgements from Acumatica

Once an Amazon order exists in Acumatica as a sales order, the first thing that travels back to Amazon is the purchase order acknowledgement. There are two documented ways to export it: one at a time, or several at once.

Acknowledging a single Amazon order

Choose the required order on the Sales Orders screen, click the Actions button, and choose the Send Acknowledgement to Amazon option. After the action finishes, the Acknowledgement status changes to closed. That status change on the sales order is the confirmation that Amazon has the acknowledgement, and it is the field to check when someone asks whether an order was acknowledged.

Acknowledging many Amazon orders at once

For volume, open Export Amazon PO Acknowledgement from Process Orders. This screen sends an API request to the Biz-Tech server, and the server in turn sends a request to the Amazon system to create the acknowledgement for the order. Choose the required orders by checking their checkboxes and press the Process button. The Biz-Tech Services Acumatica Amazon connector can also send acknowledgements automatically with a Success status.

Acknowledging with a Failure status to cancel

If an order must be cancelled, the Amazon acknowledgement is sent with a Failure status instead, and the Cancel reason field is required. The alternative route is Manually export Amazon PO Acknowledgement from Process Orders: choose the required order by checking its checkbox, click the Set Status Failure button, choose the Cancel Reason from the column below, press Save, and then Send Acknowledgement. This is why the Cancel Reasons tab has to be populated during setup; without it the cancellation cannot be completed.

Reflecting an Amazon-side cancellation back in Acumatica

The other direction is also documented. To cancel an order that already exists in Acumatica, cancel the order in Amazon, then open the Amazon Orders screen and press the Update Order button. That button updates the Amazon status in Acumatica so the two systems agree. Without it, Acumatica keeps working an order Amazon has already killed.

Outbound: Exporting Amazon Fulfillments from Shipments and Invoices

After the acknowledgement, fulfillment follows the ordinary Acumatica shipping chain, with the connector attached at two points.

From the Actions menu on the sales order, click Create Shipment. The user is then redirected to the Shipments screen. There, fill in Ship Via, add a Packages record, set a tracking number, and click Confirm Shipment.

Then click Prepare Invoice. Preparing the invoice is what fulfills the exact Amazon order: it sends an API request to the Biz-Tech server, and the server sends an API request to fulfill the order in the Amazon system. The same action can be performed in bulk from the Export Amazon Fulfillments screen by choosing the required shipments and pressing Process. The final step is navigating to the Invoice from Sales Orders and releasing the required invoice, which closes the accounting side of the transaction in Acumatica.

Refunds: Credit Memos and Imported Amazon Refunded Orders

Refunds move in both directions too, and the connector treats a refund initiated in Acumatica differently from a refund initiated in Amazon.

Refunding from Acumatica with a credit memo

To refund an order from the Acumatica side, open Invoices and Memos from Receivables, choose the required invoice, click Actions, and then Reverse. Fill in the Adjustment Reason, save the changes, and release. Releasing sends an API request to the Biz-Tech server, and the server sends an API request to refund the order in the Amazon system. The Adjustment Reason is mandatory, which is the reason the Adjustment Reasons tab is part of store setup.

Importing refunds that started in Amazon

The Import Amazon Refunded Orders screen brings refunds that originated in Amazon back into Acumatica. Press the Get Orders button to load refunded orders, with a timer showing elapsed time until the process is complete. The refunded Amazon orders are displayed on the Amazon Refund screen. Choose the required orders by checking their checkboxes and press Process, or click Process All to import every refunded order shown.

How the connector handles each refund case

What the Biz-Tech Services Acumatica Amazon integrator connector does next depends entirely on how far the original order had progressed, and five cases are defined. In case one the refunded order is still only a sales order with no fulfillment. If it consists of one item, processing creates a Payment of the Customer Refund type, attaches it on the Payments tab, sets the refunded amount, and closes the order; following the Reference number shows that payment and the refunded amount on the Application History tab. The sales order status changes to Canceled and all lines are deleted.

Still within case one, if the order consists of several items, the refunded quantity is reduced from the order quantity and the system creates a Payment document attached on the Payments tab for the refunded items, while the order status remains Open. A partial refund therefore leaves a working order behind rather than cancelling the whole thing.

Case two covers a shipment that has been created but not confirmed: pressing Process finds it, deletes it, and then proceeds with the case one actions above. Case three covers a confirmed shipment, where the system creates a Credit Memo and attaches the Reference number with the Customer Refund type to Applications. Case four, an invoice prepared but not released, produces the same Credit Memo.

Case five is the fully posted scenario, where the invoice has already been released. Here the system reverses the invoice and generates a Credit Memo with a Customer Refund type Reference number attached to Applications. In every case, once the actions complete, the Processed checkbox on the Refunds tab is automatically checked on the Amazon Orders screen for the corresponding order, which means the process is over and the order is Closed. The credit memo itself is created in the Invoices screen of Sales Orders.

Item and Inventory Quantity Sync from Acumatica to Amazon

The Export Amazon Inventory Quantity screen syncs Acumatica and Amazon inventory quantities through the Biz-Tech server. Its behavior is governed by a checkbox on each line, and the distinction is easy to miss. If the checkbox is not selected, the Sync action updates the Amazon inventory quantity based on the number in the Quantity column, that is, the Acumatica quantity. If a user wants to send a different number to Amazon, change the value in the Amazon Quantity column, check the checkbox, and then press the Sync button, and the Amazon inventory quantity is updated to that value.

That override is useful when your business deliberately holds stock back from the marketplace, and it is also the reason listed availability can drift from Acumatica availability without anyone noticing. The quantity sent is still governed by the Warehouse Details tab: the sum across the selected warehouses, on the On hand, Available, or Available for Shipment basis chosen there.

FBA Settings: Configuring Fulfillment by Amazon in Acumatica

The Amazon Store screen carries a tab that provides access to all the settings for Amazon FBA orders. It is organized into order options, warehouse mapping, shipment options, customer information, and a payment option, and each group maps onto a distinct part of the FBA flow.

FBA Default Order Options

Invoice Type is the document created after an Amazon FBA order is received and imported, because an FBA order is imported as an invoice in Acumatica rather than as a sales order to be picked. Begin Order date filters the data retrieval, and Last Imported Order Date records when the last order was imported. Below the dates is a table for mapping Acumatica statuses to Amazon order statuses by selecting the corresponding status, so the connector knows which Amazon states are meaningful in your Acumatica workflow. To retrieve and import an order, the corresponding Order Status checkbox must be selected.

FBA Warehouse and fulfillment center mapping

Destination warehouse sets up the warehouse in Acumatica where Amazon goods or products are intended to be sent or delivered. When the Enable Ship from Mapping checkbox is selected, a mapping section opens between the Amazon Fulfillment Center and the Ship-from Warehouse ID, letting your business map an Amazon fulfillment center to an Acumatica warehouse ID and determine which warehouse ships product to the destination warehouse. If the checkbox is not selected, the section disappears and the single value in the Ship from Warehouse ID field is used instead. Businesses shipping into several Amazon fulfillment centers from several of their own sites need the mapping; a single-warehouse seller does not.

FBA Default Shipment Options

Destination Order Type should be populated with the Transfer order type, because all FBA orders need to be created using that specific order type. A Destination Order Type checkbox is included for transfer order types, and when it is selected the Order Type field is disabled, indicating that it is an Amazon FBA order type. One configuration rule is stated explicitly and is easy to trip over: the same order type can only be configured in one store and cannot be repeated in other stores.

Two checkboxes decide what is retrieved. Select Shipments imports FBA shipments, and Select Deliveries imports FBA deliveries. Two date fields report progress: Last Imported Shipment Date is the date the last shipment was imported from Amazon into an Acumatica transfer order, and Last Imported Deliveries Date is the date the last delivery was imported into an Acumatica purchase receipt. Below the dates, a table displays the corresponding Amazon shipment status to be imported into Acumatica.

Two more checkboxes change the resulting documents. When Release PO Receipt During FBA Shipment Import is selected, the shipment is imported as already released into the purchase receipt, which removes a manual release step for businesses that trust the Amazon numbers. Override FBA Shipment bill address information controls whether the order import overrides the customer addresses and sets the Acumatica order address on the sales order, or sets the customer billing address instead.

FBA customer and payment options

The Customer field sets the default customer used during the order import process from Amazon to Acumatica, and it is required for the Amazon orders import process. Under FBA Payment Option, selecting Import Amazon FBA Payment opens a further field for the payment method name, so a payment method can be set up and imported for the FBA order.

The FBA Process Flow: Shipments, Transfers, Deliveries, and Orders

The FBA flow in Acumatica is best read as two tracks. One track moves your stock into Amazon fulfillment centers and keeps the inventory numbers honest. The other track brings the resulting Amazon sales in as invoices.

Importing FBA shipments as transfer orders

To transfer and update items in a single shipment, the FBA shipments must first be pulled from Amazon Seller Central into Acumatica. When a shipment is imported, it creates a sales order with the Transfer order type already selected and set up in the FBA store. The grid displays the destination warehouse where the item will be received, and the sales order line shows the warehouse the item should be transferred from. Selecting the pre-configured Transfer order type established in the store displays the store code on the Sales Orders screen, which is how a user tells an FBA transfer apart from an ordinary internal one.

Updating warehouses with Update In

Upon confirming the shipment of the transfer order and clicking the Update In button, the system updates the warehouse by transferring items from the source warehouse to the destination warehouse. This is the step where Acumatica inventory finally reflects that the goods are in Amazon custody rather than on your own shelves.

Importing FBA deliveries as purchase receipts

After the items have been updated in the warehouses and the shipments are closed in Seller Central, go to the Import FBA Deliveries screen to retrieve all shipments. They are then displayed on the Purchase Receipt screen and are already in the destination warehouse. Following the purchase order release process, the quantity in the destination warehouse is updated and displayed.

Quantity rules on the Import FBA Shipments screen

The Import FBA Shipments screen handles the retrieval and importation of all shipments from Amazon into Acumatica and creates a purchase receipt based on the received quantity of the shipment. Three quantity outcomes are documented. If the received and shipped quantities are equal, the order imports without any issues. If the received quantity is smaller than the shipped quantity, the order still imports. If the received quantity exceeds the shipped quantity, an error message appears stating that the received quantity is greater than the shipped quantity. To prevent that, item quantities need to be adjusted on the FBA Shipments screen before importing.

Importing the FBA orders themselves

The Import FBA Orders screen gets and imports all Amazon FBA orders into Acumatica according to the dates and statuses configured on the store, and after importing it creates a sales order invoice. Imported FBA orders are displayed on the Invoices screen of Sales Orders, which is where users should look for them rather than in an open sales order list.

Where to Monitor Amazon Results in Acumatica

Most support questions about an Biz-Tech Services Acumatica Amazon integration reduce to one question: did the record make it, and if not, where did it stop? These are the exact places in Acumatica to look:

  • Import Amazon Orders grid, where a red cross on an order line signals a failure; hover over it for detail, or open Tools and then Trace for more.
  • Amazon Orders screen, opened by clicking the Order Number, which shows the key order information and the error message explaining what should be fixed and in which system.
  • Email notifications listing Order IDs with errors, if the Send Email Notifications for Errors checkbox is selected on FBM Settings.
  • Last Imported Order Date on the FBM Settings tab, and its equivalent on FBA settings, to confirm the flow is still running.
  • Acknowledgement status on the sales order, which changes to closed once Send Acknowledgement to Amazon has finished.
  • The Delivery Settings area of the Shipping tab on Sales Orders, where the cross-referenced Ship Via value should appear after import.
  • Payments tab and Application History tab, where a Customer Refund payment and the refunded amount are recorded against the Reference number.
  • Refunds tab on the Amazon Orders screen, where the Processed checkbox is checked automatically once a refund is fully handled and the order is Closed.
  • Invoices screen of Sales Orders, where credit memos from refunds and imported FBA order invoices both appear.
  • FBA Shipments screen, a set of generic inquiries giving compact information about shipments in both Acumatica and Amazon.
  • FBA Destination Warehouse Quantities screen, which tracks warehouse updates and shows item quantities in both the destination warehouse and the current warehouse.
  • FBM and FBA Orders screen, where the Fulfillment channel field identifies which channel each order came through.

Amazon Acumatica Integration: Frequently Asked Questions

What is the difference between FBA and FBM in the Amazon Connector for Acumatica?

FBM, Fulfillment by Merchant, means your business ships the order, so the Biz-Tech Services Acumatica Amazon integrator imports it as a sales order and you run Create Shipment, Confirm Shipment, and Prepare Invoice, with the fulfillment event going back to Amazon. FBA, Fulfillment by Amazon, means your products sit in Amazon fulfillment centers and Amazon handles storage, packing, shipping, and customer service, so the Biz-Tech Services Acumatica Amazon connector imports FBA shipments as transfer orders, FBA deliveries as purchase receipts, and the FBA orders themselves as invoices. The two channels have separate settings tabs and separate processing screens, and the FBM and FBA Orders screen shows both, distinguished by the Fulfillment channel field.

Are Amazon orders imported into Acumatica as sales orders or as invoices?

Both are supported. The Biz-Tech Services Acumatica Amazon integration can import Amazon orders as either the sales order or the invoice document type, and the Order Type field on the FBM Settings tab sets the default for FBM. For FBA the answer is fixed: an imported Amazon FBA order becomes an invoice, controlled by the Invoice Type field on the FBA settings tab, and those invoices appear on the Invoices screen of Sales Orders.

Why does my Amazon order import fail with an item error?

The most likely cause is the Import Item checkbox on the Amazon Store screen. When it is selected, the Biz-Tech Services Acumatica Amazon integrator imports product information for items that do not yet exist in Acumatica; when it is not selected and an unknown Amazon item arrives, an error occurs during integration. Check that checkbox first, then check whether the SKU is mapped on the Inventory Details tab of the Amazon Store screen. The full error text is shown on the Amazon Orders screen and explains what should be fixed and in which system.

How do I see the exact error behind a failed Amazon order import?

There are three places, in increasing order of detail. On the Import Amazon Orders grid, hover the cursor over the red cross on the failing order line to see additional information. Click the Order Number to open the Amazon Orders screen, where the error message states what should be fixed and in which system. For anything still unclear, open Tools and then Trace for the underlying detail.

What does the error “Received quantity is greater than the shipped quantity” mean?

It appears on the Import FBA Shipments screen when the received quantity on an Amazon FBA shipment exceeds the quantity shipped, and it blocks the import. Equal received and shipped quantities import cleanly, and a received quantity lower than the shipped quantity still imports. To clear the error, adjust the item quantities on the FBA Shipments screen before importing again.

How do I cancel an Amazon order from Acumatica?

Send the Amazon acknowledgement with a Failure status and fill the required Cancel reason field. From Process Orders, open Manually export Amazon PO Acknowledgement, check the order, click Set Status Failure, choose the Cancel Reason, press Save, and then Send Acknowledgement. Cancel reasons must already exist on the Cancel Reasons tab of the Amazon Store screen, otherwise the cancellation cannot be completed. If the cancellation happened in Amazon instead, open the Amazon Orders screen and press Update Order to bring the Amazon status into Acumatica.

What happens when an Amazon order is refunded after the invoice was released?

That is case five of the refund logic. When you process the refunded order on the Import Amazon Refunded Orders screen, the system reverses the invoice and generates a Credit Memo carrying a Reference number of the Customer Refund type attached to Applications. Once the actions finish, the Processed checkbox on the Refunds tab of the Amazon Orders screen is checked automatically and the order is Closed. The credit memo itself is created on the Invoices screen of Sales Orders.

Work With the Biz-Tech Services Amazon Connector

Traced end to end, the flow is coherent: credentials on the Connection Settings tab open the channel to the Biz-Tech intermediate server, the FBM Settings and FBA settings tabs decide what imported records look like, the cross-reference, warehouse, carrier, and reason tabs translate Amazon values into Acumatica ones, and the processing screens move orders, acknowledgements, fulfillments, refunds, and quantities in the appropriate direction. FBM runs through sales orders, shipments, and invoices; FBA runs through transfer orders, purchase receipts, and invoices. When something goes wrong, the Amazon Orders screen, the red cross tooltip, the trace, and the Processed checkbox on the Refunds tab tell your business exactly where the record stopped.

If your business sells on Amazon and wants that activity landing in Acumatica ERP as accurate orders, shipments, invoices, refunds, and inventory quantities, the Biz-Tech Services Amazon Connector is built for exactly that. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration.

The post How Amazon FBA and FBM Data Flows into Acumatica ERP appeared first on Biz-Tech Services.

]]> QuickBooks to Acumatica Migration Guide 2026 | Complete ERP Transition Guide https://biz-techservices.com/archives/10245 Thu, 06 Aug 2026 16:39:48 +0000 https://biz-techservices.com/?p=10245 QuickBooks to Acumatica Migration Guide 2026: When to Upgrade, What It Costs, and How to Migrate Successfully QuickBooks can be […]

The post QuickBooks to Acumatica Migration Guide 2026 | Complete ERP Transition Guide appeared first on Biz-Tech Services.

]]>

QuickBooks to Acumatica Migration Guide 2026: When to Upgrade, What It Costs, and How to Migrate Successfully

QuickBooks can be an excellent starting point for a small business. It helps companies establish financial discipline, manage invoices and bills, track income and expenses, and build a reliable accounting foundation without immediately taking on the cost and complexity of a complete enterprise resource planning system.

The problem is not that QuickBooks suddenly becomes “bad” when a company grows.

The problem is that a growing business eventually becomes more than an accounting process.

It develops multiple warehouses, new sales channels, more complex inventory, larger purchasing operations, project accounting requirements, manufacturing workflows, field operations, intercompany activity, eCommerce stores, marketplace orders, customer-specific pricing, shipping integrations, payment systems, and reporting demands that reach far beyond the general ledger.

At that stage, the company often begins using QuickBooks together with spreadsheets, inventory applications, CRM software, warehouse tools, eCommerce plugins, shipping platforms, payment portals, reporting databases, and custom workarounds. Every individual tool may solve a legitimate problem, but the complete operating environment becomes fragmented.

Orders are entered more than once. Inventory quantities differ between systems. Financial reports are correct only after manual reconciliation. Customer data is duplicated. Warehouse teams work from exports. Management dashboards are delayed. Employees spend more time moving information than using it.

This is usually the point when businesses begin researching:

  • QuickBooks to Acumatica migration;
  • Acumatica vs QuickBooks;
  • QuickBooks Enterprise alternative;
  • cloud ERP replacement for QuickBooks;
  • how to migrate QuickBooks to Acumatica;
  • Acumatica implementation partner;
  • QuickBooks to ERP migration cost.

Moving from QuickBooks to Acumatica Cloud ERP is not simply an accounting software upgrade. It is a transition from an accounting-centered system to a connected business management platform that can unite financials, inventory, purchasing, sales orders, warehouses, manufacturing, projects, field service, CRM, reporting, eCommerce, payments, and integrations.

That transition can create significant operational value, but only when it is planned carefully.

A successful QuickBooks to Acumatica migration requires more than exporting lists and importing spreadsheets. The company must decide what data should move, what data should be cleaned, how the chart of accounts should evolve, how open receivables and payables should be represented, how inventory should be reconciled, how historical transactions should remain accessible, and how all external systems will connect to Acumatica after go-live.

As an Acumatica Gold Partner, BizTech helps companies manage the complete transition. Our work can include business process discovery, Acumatica implementation, QuickBooks data migration, financial reconciliation, inventory setup, custom development, eCommerce integration, marketplace automation, payment integration, testing, training, cutover planning, and post-go-live support.

This guide explains when a business should move beyond QuickBooks, how Acumatica differs from accounting software, what can be migrated, how the migration process works, what affects cost and timeline, which mistakes to avoid, and why the implementation partner matters.

QuickBooks Is Not One Product: Define the Source Before Planning the Migration

Before comparing QuickBooks with Acumatica, it is important to clarify what “QuickBooks” means in the context of the migration.

QuickBooks is a product family. A company may be using:

  • QuickBooks Online;
  • QuickBooks Online Advanced;
  • QuickBooks Desktop;
  • QuickBooks Desktop Enterprise;
  • QuickBooks Enterprise with cloud hosting;
  • industry-specific QuickBooks Enterprise configurations;
  • QuickBooks connected to third-party inventory, payroll, eCommerce, CRM, reporting, or warehouse applications.

These environments are not identical.

QuickBooks Enterprise can provide more advanced functionality than entry-level accounting editions, including industry-specific tools, advanced inventory options, sales order fulfillment features, job costing, multi-company capabilities, and connected applications. Therefore, a fair Acumatica vs QuickBooks comparison should not pretend that every QuickBooks user has only basic bookkeeping features.

The real question is not whether QuickBooks has useful functionality.

The real question is whether the complete QuickBooks-centered environment still supports the company efficiently as complexity increases.

A migration assessment must identify:

  • the exact QuickBooks product and edition;
  • the version and hosting arrangement;
  • the number of company files;
  • the number of years of data;
  • enabled inventory, payroll, project, and industry features;
  • connected applications;
  • custom reports and fields;
  • manual spreadsheets used outside QuickBooks;
  • operational processes that QuickBooks does not manage directly.

This source-system inventory affects the migration scope, data extraction method, field mapping, integration plan, timeline, testing, and cost.

A company moving from QuickBooks Online with limited inventory and one entity will have a different project from a distributor moving from QuickBooks Enterprise with several warehouses, advanced inventory, custom pricing, eCommerce applications, and years of transaction history.

When QuickBooks Stops Being Enough

QuickBooks often remains useful even after a company begins feeling operational pressure. Finance may still close the books. Invoices may still be generated. Bills may still be paid. Management may still receive financial statements.

The first signs of a problem usually appear outside accounting.

The warehouse may be working from a separate system. Sales representatives may not see reliable inventory. eCommerce orders may be imported manually. Customer service may need to check several applications before answering a question. Managers may wait for spreadsheets to understand profitability. Multiple company files may require manual consolidation. Manufacturing may depend on separate BOM, scheduling, or costing tools.

The accounting system continues working, but the operating model becomes increasingly difficult to manage.

Acumatica describes this transition in terms of manual processes, disconnected systems, fragmented data, limited real-time visibility, increasing financial complexity, multiple entities or locations, and business requirements that exceed entry-level accounting software.

The key distinction is this:

QuickBooks may still be capable of recording the financial result after work happens, while the business increasingly needs a system that also manages and coordinates the work itself.

That need becomes more urgent when employees are spending significant time on:

  • re-entering transactions;
  • exporting and merging spreadsheets;
  • reconciling inventory between platforms;
  • checking whether orders were shipped;
  • matching online payments to invoices;
  • consolidating company files;
  • creating manual management reports;
  • correcting inconsistent customer or item records;
  • maintaining integrations that frequently fail.

At that point, continuing to add isolated tools can cost more than moving to a connected ERP platform.

Acumatica vs QuickBooks: Accounting Software vs a Connected ERP Platform

The most useful comparison is not “small software vs large software.” It is a comparison of system roles.

QuickBooks is primarily recognized as accounting software, although advanced QuickBooks editions can extend into inventory, order management, job costing, multi-company operations, and industry-specific use cases.

Acumatica is a complete cloud ERP and business management platform designed to connect financial activity with operational processes.

Business area QuickBooks-centered environment Acumatica Cloud ERP
Financial management Strong accounting foundation; capabilities vary by edition Financial management connected directly to operations, projects, inventory, and industry workflows
Inventory Available in selected editions and configurations; advanced requirements may involve add-ons Integrated inventory, warehouses, locations, allocations, availability, purchasing, sales, and financial posting
Distribution Can support selected order and inventory workflows, often with connected applications End-to-end distribution management with purchasing, inventory, sales orders, fulfillment, pricing, and reporting
Manufacturing QuickBooks Enterprise provides manufacturing and wholesale features, but complex production may require additional systems BOMs, routing, production management, MRP, planning, costing, engineering changes, and shop-floor capabilities
Construction and projects Job costing and project features vary by edition; broader field and project workflows may be external Project accounting, job costing, commitments, change orders, billing, field collaboration, and project reporting
CRM Frequently managed through another application CRM connected with customers, opportunities, orders, invoices, service, and financial history
eCommerce and marketplaces Typically connected through applications, imports, or middleware Can serve as the central ERP behind commerce connectors, orders, inventory, payments, fulfillment, refunds, and reporting
Workflow automation Often dependent on edition, add-ons, or external automation Configurable workflows, business events, approvals, notifications, APIs, webhooks, and custom automation
Reporting Strong accounting reports; cross-system operational reporting may require exports or external tools Financial reports, Generic Inquiries, dashboards, role-based analytics, operational KPIs, and BI integrations
User access User allowances and roles depend on the QuickBooks product and subscription Acumatica promotes unlimited user access with pricing based on applications and resource consumption
System architecture Varies across Online, Desktop, Enterprise, hosting, and connected application environments Unified cloud ERP platform with open APIs, extensibility, and industry editions

The strongest reason to move is not that Acumatica contains more menu options.

It is that Acumatica can replace many disconnected handoffs with one governed operating model.

Twelve Signs Your Business Has Outgrown QuickBooks

A business should not migrate simply because it reached a certain revenue or employee number. Operational complexity is a better indicator than company size.

The following signs suggest that the organization should evaluate a move from QuickBooks to Acumatica.

1. Manual Data Entry Is Increasing Faster Than Revenue

Employees repeatedly enter orders, customers, inventory adjustments, payments, or shipping information into more than one application.

Growth should create more business activity, not an equal increase in administrative re-entry.

2. Excel Has Become a Parallel ERP

Spreadsheets are used to manage inventory, order status, purchasing, forecasts, production, projects, commissions, or management reporting.

Spreadsheets are useful analytical tools, but they become risky when they are the only place where critical operational truth exists.

3. Reports Are Correct Only After Manual Reconciliation

Management cannot rely on a dashboard without first waiting for finance or operations to combine information from several systems.

By the time the report is complete, the underlying business may already have changed.

4. Inventory Is Managed Outside the Accounting System

Warehouse quantities, allocations, serial or lot information, reorder decisions, or fulfillment status are controlled by another application or spreadsheet.

This often creates disagreements between physical stock, operational systems, and accounting records.

5. The Company Operates Several Locations, Entities, or Warehouses

Multiple QuickBooks company files, manual consolidations, intercompany spreadsheets, and inconsistent processes make financial and operational control increasingly difficult.

6. Orders Come from Several Sales Channels

The business receives orders through direct sales, Shopify, WooCommerce, Amazon, Magento, retailers, EDI networks, or marketplaces.

Manual imports and fragmented integrations increase the risk of duplicate orders, incorrect taxes, delayed fulfillment, and inventory overselling.

7. Customer Data Is Fragmented

Sales, finance, service, eCommerce, and warehouse teams each see a different version of the customer.

A connected ERP should show quotes, orders, invoices, payments, service history, shipments, returns, and project activity in one environment.

8. Profitability Is Difficult to Measure

The company can see revenue but struggles to measure true margin by product, customer, channel, warehouse, project, or job.

This is especially common when fulfillment, fees, returns, labor, and inventory costs live outside the accounting system.

9. Financial Close Takes Too Long

Finance must reconcile eCommerce systems, inventory applications, payment processors, project tools, and spreadsheets before closing the period.

A connected ERP can reduce the number of manual reconciliations required.

10. Integrations Frequently Break or Require Manual Supervision

Connected apps may work independently but lack centralized error handling, audit history, retry logic, or consistent mapping.

Employees begin monitoring integrations manually and repairing data after failures.

11. More Administrative Headcount Is Needed to Maintain the Same Process

The company adds staff primarily to copy data, reconcile systems, prepare reports, and manage exceptions.

ERP automation should allow transaction volume to grow faster than administrative workload.

12. Business Decisions Are Being Limited by the Current System

The company avoids opening a new warehouse, adding an entity, expanding eCommerce, introducing manufacturing, or changing processes because the existing software environment cannot support the change cleanly.

When the system begins determining strategy, the business has likely outgrown it.

What Businesses Gain by Moving from QuickBooks to Acumatica

A successful migration should create measurable improvements, not merely replace one interface with another.

The major benefits can include:

One Source of Financial and Operational Truth

Financial activity, inventory, purchasing, sales orders, projects, manufacturing, service, commerce, and reporting can operate from a shared data model.

Real-Time Inventory Visibility

Users can see quantities by warehouse and location, availability, allocations, purchase orders, sales demand, and transaction history without reconciling separate tools.

Faster and More Reliable Reporting

Dashboards and reports can use live ERP data rather than waiting for manual consolidation.

Workflow Automation

Approvals, notifications, document creation, synchronization, and exception handling can be automated.

Broad User Access

Acumatica’s unlimited user philosophy can make it easier to include warehouse users, managers, project teams, customer service, and other departments.

Connected eCommerce and Marketplace Operations

Acumatica can become the ERP foundation behind Shopify, WooCommerce, Amazon, Magento, retail networks, shipping systems, warehouses, and payment providers.

Scalable Industry Functionality

The organization can expand into distribution, manufacturing, construction, project accounting, field service, CRM, and other applications without rebuilding its entire system architecture.

Open Integration Architecture

APIs, webhooks, import scenarios, business events, and custom extensions support connected operations.

Stronger Controls and Auditability

Roles, approvals, document history, transaction links, and workflow records improve accountability.

A Platform for Future Growth

The migration creates a foundation for new companies, locations, channels, products, integrations, and automation.

What Data Can Be Migrated from QuickBooks to Acumatica?

Most essential business data can be migrated, but the exact scope depends on the QuickBooks product, data quality, Acumatica configuration, and historical requirements.

Common migration categories include:

Financial Structure

  • chart of accounts;
  • account types;
  • departments, classes, or dimensions;
  • opening general ledger balances;
  • financial periods;
  • tax settings;
  • currencies;
  • company and branch relationships.

Customers and Receivables

  • customer records;
  • billing and shipping addresses;
  • contacts;
  • payment terms;
  • tax information;
  • credit limits;
  • open invoices;
  • credit memos;
  • unapplied payments;
  • customer balances;
  • aging details.

Vendors and Payables

  • vendor records;
  • addresses and contacts;
  • payment terms;
  • tax identifiers;
  • open bills;
  • vendor credits;
  • unapplied payments;
  • vendor balances;
  • aging details.

Inventory and Product Data

  • inventory items;
  • non-stock items;
  • SKUs;
  • descriptions;
  • item classes;
  • units of measure;
  • cost information;
  • sales prices;
  • vendor relationships;
  • warehouse assignments;
  • opening quantities;
  • lot or serial details where available and required;
  • reorder information;
  • assemblies or product structures where mapping is practical.

Open Operational Documents

  • open sales orders;
  • open purchase orders;
  • open estimates or quotes;
  • open projects or jobs;
  • customer deposits;
  • vendor prepayments;
  • unshipped or partially fulfilled documents.

Historical Transactions

Depending on strategy, historical data may include:

  • general ledger transactions;
  • sales invoices and payments;
  • vendor bills and payments;
  • inventory transactions;
  • sales and purchase history;
  • project or job history;
  • bank activity;
  • attachments and source documents.

Not every field or relationship transfers directly. Some data must be transformed to fit the new Acumatica design.

What Data Should Not Be Migrated Automatically?

A migration is an opportunity to improve data quality.

Moving every historical record without evaluation can transfer years of errors and obsolete structures into the new ERP.

Data that should be reviewed carefully includes:

Duplicate Customers and Vendors

The same organization may appear several times under different names, spellings, addresses, or company files.

Duplicates should be identified and consolidated before import.

Inactive or Obsolete Records

Old customers, discontinued vendors, obsolete products, inactive accounts, and expired projects may not belong in the production ERP.

Some records may be retained in an archive rather than migrated as active master data.

Unreconciled Financial Balances

If the source books do not reconcile, importing the same values does not solve the problem.

Financial differences should be investigated and approved before opening balances are loaded.

Unreliable Inventory Quantities

An inaccurate source quantity should not become the opening quantity in Acumatica.

Physical counts and reconciliation may be required before cutover.

Legacy Custom Fields Without Current Business Value

Some fields exist only because of old workarounds. The business should confirm whether they still support a real process.

Unnecessary Transaction Detail

A company may not need every historical line in the live ERP. Summary balances, limited history, or an archive may provide better value.

Old Workarounds

Spreadsheets and coding conventions created to overcome QuickBooks limitations should not automatically define the Acumatica design.

The migration should preserve business requirements, not unnecessary constraints.

The QuickBooks to Acumatica Migration Process

A structured migration reduces risk and creates clear approval points.

Phase 1: Business Discovery

The project begins with understanding the company, not exporting data.

BizTech reviews:

  • business model and industry;
  • QuickBooks edition and version;
  • company files;
  • entities, branches, and locations;
  • financial processes;
  • sales and purchasing workflows;
  • inventory and warehouse operations;
  • manufacturing, construction, service, or project requirements;
  • eCommerce and marketplace channels;
  • payment and shipping systems;
  • management reporting;
  • growth plans.

The output is a documented view of the current state and target operating model.

Phase 2: Data Audit

The team evaluates:

  • data sources;
  • record volumes;
  • duplicates;
  • missing fields;
  • custom fields;
  • historical depth;
  • open balances;
  • inventory accuracy;
  • attachments;
  • reconciliation status.

The audit determines what can be migrated directly, what requires transformation, and what should remain archived.

Phase 3: Acumatica Solution Architecture

The target design may define:

  • companies and branches;
  • chart of accounts;
  • subaccounts and reporting dimensions;
  • customer and vendor classes;
  • item classes;
  • warehouses and locations;
  • order types;
  • tax configuration;
  • security roles;
  • approval workflows;
  • required applications;
  • integration architecture;
  • reporting structure.

Data mapping cannot be finalized until the target structure is approved.

Phase 4: Data Cleansing and Transformation

Source records are standardized and prepared.

Activities may include:

  • merging duplicates;
  • standardizing names and addresses;
  • normalizing item IDs;
  • mapping accounts;
  • assigning customer, vendor, and item classes;
  • mapping units of measure;
  • defining default warehouses;
  • reconciling open balances;
  • removing obsolete records;
  • preparing import files.

Phase 5: Acumatica Configuration

BizTech configures the approved Acumatica environment, including financial management, inventory, sales, purchasing, projects, manufacturing, construction, CRM, commerce, and other required functionality.

Phase 6: Test Migration

A test migration validates the design before final cutover.

The team imports representative data and checks:

  • record counts;
  • field mappings;
  • account balances;
  • customer and vendor balances;
  • inventory quantities and values;
  • open documents;
  • tax configuration;
  • reporting;
  • integration references.

A serious migration should not rely on the first import being correct.

Phase 7: Integrations and Automation

External systems are connected to the new Acumatica environment.

This may include Shopify, WooCommerce, Amazon, Magento, PayPal, ShipHero, ShipStation, Salesforce, ServiceTitan, DSCO, CommerceHub, EDI, tax systems, banks, BI platforms, and proprietary applications.

Phase 8: Financial and Operational Reconciliation

The team validates that Acumatica matches approved source totals.

Reconciliation may include:

  • trial balance;
  • accounts receivable aging;
  • accounts payable aging;
  • cash balances;
  • inventory quantity and value;
  • open sales orders;
  • open purchase orders;
  • project balances;
  • fixed assets;
  • retained earnings.

Phase 9: User Acceptance Testing

Users execute real business scenarios such as:

  • creating and fulfilling a sales order;
  • receiving a purchase order;
  • processing an invoice and payment;
  • handling a return or credit;
  • moving inventory between warehouses;
  • running production or project workflows;
  • importing an eCommerce order;
  • exporting shipment tracking;
  • running financial and operational reports.

Phase 10: User Training

Training is delivered by role and process.

Users should learn not only which buttons to press, but also how the new process differs from QuickBooks and how to handle exceptions.

Phase 11: Final Cutover

The final cutover typically includes:

  • source transaction freeze;
  • final backups;
  • final data extraction;
  • production migration;
  • reconciliation;
  • integration activation;
  • user access validation;
  • go-live approval.

Phase 12: Post-Go-Live Support and Optimization

The team monitors transactions, user questions, integrations, reports, and performance.

Some process improvements are intentionally scheduled after users gain real production experience.

QuickBooks Chart of Accounts Migration to Acumatica

The chart of accounts should not always be copied exactly.

QuickBooks accounts may have been designed around the limitations of the previous system, reporting habits, classes, locations, or separate company files. Acumatica provides additional structural tools such as branches, subaccounts, and dimensions that can improve reporting without creating an unnecessarily large chart of accounts.

The migration process may include:

  • reviewing existing accounts;
  • removing duplicates and inactive accounts;
  • mapping QuickBooks accounts to Acumatica accounts;
  • converting classes, departments, or locations into subaccount segments or other dimensions;
  • defining branch relationships;
  • designing consolidated reporting;
  • mapping retained earnings and control accounts;
  • loading opening balances;
  • validating the trial balance.

The goal is not to create the smallest chart of accounts or the largest one.

The goal is to create a structure that supports accurate posting, management reporting, auditability, and future growth.

QuickBooks Customer and Vendor Migration

Customer and vendor records influence sales, purchasing, payments, taxes, credit, shipping, integrations, and reporting.

A clean migration may include:

Customer Data

  • customer ID and name;
  • customer class;
  • billing and shipping addresses;
  • contacts and email addresses;
  • payment terms;
  • tax zones and exemptions;
  • credit limits;
  • preferred payment methods;
  • salesperson assignments;
  • eCommerce or marketplace identifiers;
  • open balances.

Vendor Data

  • vendor ID and name;
  • vendor class;
  • addresses and contacts;
  • payment terms;
  • tax information;
  • payment instructions;
  • currency;
  • default expense or inventory relationships;
  • open balances.

Duplicate Management

The business should define matching rules using names, addresses, tax IDs, email addresses, phone numbers, and legacy identifiers.

Duplicate records should not be merged automatically without business review because different records may represent separate legal entities, locations, or billing relationships.

QuickBooks Inventory Migration to Acumatica

Inventory migration is usually more complex than customer or vendor migration because quantities, values, units, locations, costs, and operational status must agree.

The migration may include:

  • inventory and non-stock items;
  • SKUs and alternate IDs;
  • item classes;
  • descriptions;
  • units of measure;
  • sales and purchase units;
  • warehouses;
  • warehouse locations;
  • opening quantities;
  • inventory value;
  • standard, average, or other costing considerations;
  • lot and serial information;
  • vendor item relationships;
  • sales prices;
  • reorder points;
  • safety stock;
  • lead times;
  • product attributes;
  • eCommerce and marketplace references.

Inventory Reconciliation

Before final migration, the business should compare:

  • QuickBooks quantities;
  • warehouse system quantities;
  • eCommerce availability;
  • physical inventory;
  • inventory value in the general ledger.

If these sources disagree, the company must approve the authoritative quantity and value before go-live.

Assemblies and Manufacturing Data

QuickBooks assemblies may need to be transformed into Acumatica bills of material, kit specifications, or other structures depending on the target manufacturing and inventory design.

This is not always a one-to-one field import. Routing, labor, overhead, scrap, revisions, and planning rules may need to be designed separately.

Migrating Open Accounts Receivable and Accounts Payable

Open AR and AP documents must be migrated carefully because they affect cash flow, aging, customer and vendor balances, payment application, and the opening trial balance.

Open Accounts Receivable

The migration may include:

  • customer invoices;
  • credit memos;
  • unapplied payments;
  • deposits;
  • document dates;
  • due dates;
  • payment terms;
  • reference numbers;
  • remaining balances;
  • applications between payments and invoices.

Open Accounts Payable

The migration may include:

  • vendor bills;
  • vendor credits;
  • prepayments;
  • unapplied payments;
  • document dates;
  • due dates;
  • payment terms;
  • reference numbers;
  • remaining balances.

Reconciliation Requirements

After import:

  • AR aging must match the approved source aging;
  • AP aging must match the approved source aging;
  • customer and vendor totals must agree with control accounts;
  • unapplied payments must remain traceable;
  • opening balances must not duplicate migrated documents.

This is one of the most important checkpoints in the migration.

Should Historical QuickBooks Transactions Be Migrated?

There are three common strategies.

Strategy 1: Full Detailed Historical Migration

The company migrates several years of transaction-level history into Acumatica.

Advantages:

  • users can research history in one system;
  • comparative reporting may be easier;
  • customer, vendor, and item history remains directly accessible;
  • the legacy system may be retired more completely.

Disadvantages:

  • higher cost and longer timeline;
  • more field mapping and data transformation;
  • greater reconciliation effort;
  • legacy errors and structures are more likely to be transferred;
  • some transaction relationships may not map perfectly.

Strategy 2: Limited Historical Migration

The company migrates selected periods, summarized history, or only data needed for operational continuity.

This approach balances accessibility and cost.

Strategy 3: Opening Balances Plus Legacy Archive

Acumatica begins with clean master data, opening balances, and open documents. Detailed history remains in QuickBooks, a reporting database, PDF archive, or other controlled repository.

This is often the most efficient approach, but the business must maintain reliable historical access and define retention responsibilities.

How to Choose

The decision should consider:

  • audit requirements;
  • tax retention requirements;
  • customer service needs;
  • warranty and product history;
  • project history;
  • comparative reporting;
  • legacy licensing cost;
  • migration budget;
  • data quality.

More historical data is not automatically better.

Useful, reliable, and accessible history is better.

Connecting Acumatica to the Systems QuickBooks Could Not Manage Centrally

Many companies do not migrate from QuickBooks alone. They migrate from an ecosystem built around QuickBooks.

The complete source environment may include:

  • online stores;
  • marketplaces;
  • warehouse management systems;
  • shipping platforms;
  • payment processors;
  • CRM systems;
  • retailer networks;
  • EDI platforms;
  • tax applications;
  • BI tools;
  • custom databases.

The migration plan must decide whether each system will:

  • be replaced by Acumatica functionality;
  • remain and integrate with Acumatica;
  • be replaced by another specialized application;
  • be retired after data migration.

BizTech develops and implements Acumatica solutions for many of these connected workflows.

Amazon and Acumatica

The BizTech Amazon Connector can support Amazon FBA and FBM orders, acknowledgments, fulfillment updates, tracking, inventory synchronization, warehouse mapping, payments, taxes, and refunds.

Shopify and Acumatica

The BizTech Shopify Connector can support order import, B2B workflows, items, customers, locations, warehouses, inventory, pricing, images, attributes, metafields, fulfillment, and refunds.

WooCommerce and Acumatica

The BizTech WooCommerce Connector can synchronize orders, customers, products, categories, taxes, inventory, payments, fulfillment, and tracking.

Magento and Acumatica

The BizTech Magento Connector can synchronize orders, customers, items, pricing, categories, images, inventory, fulfillment, and refunds.

PayPal and Acumatica

The BizTech PayPal Integration can support PayPal invoice creation, payment status synchronization, cancellations, refunds, transaction visibility, and customer payment links.

Warehouse and Shipping Systems

BizTech solutions can connect Acumatica with:

  • ShipHero;
  • ShipStation;
  • other warehouse, fulfillment, and shipping platforms through custom APIs.

CRM and Field Service

BizTech supports integrations including:

  • Salesforce;
  • ServiceTitan;
  • custom CRM and service applications.

Retail Networks and EDI

BizTech provides solutions for:

A migration is successful only when these connected processes are included in the target architecture.

QuickBooks to Acumatica Migration Cost

There is no fixed migration price that applies to every company.

The cost depends on:

  • QuickBooks product and edition;
  • number of company files;
  • number of entities and branches;
  • years of history;
  • record volume;
  • data quality;
  • inventory complexity;
  • open documents;
  • required Acumatica applications;
  • integrations;
  • custom fields and workflows;
  • reporting requirements;
  • testing;
  • training;
  • cutover support.

A complete budget usually contains:

Cost category Typical work
Acumatica software Applications, resource tier, storage, and deployment model
Implementation Discovery, architecture, configuration, testing, project management
Data migration Extraction, cleansing, mapping, import, validation, reconciliation
Integrations Commerce, marketplaces, payments, warehouses, shipping, CRM, EDI, APIs
Customization Custom fields, screens, workflows, logic, actions, extensions
Reporting Financial statements, dashboards, Generic Inquiries, BI integrations
Training Role-based sessions, documentation, videos, adoption support
Post-go-live support Monitoring, issue resolution, optimization, enhancements

What Reduces Migration Cost?

  • clean and reconciled source data;
  • one QuickBooks company file;
  • limited historical migration;
  • clear process ownership;
  • standard Acumatica configuration;
  • existing BizTech connectors;
  • fast client decisions;
  • well-defined reporting requirements;
  • realistic phased scope.

What Increases Migration Cost?

  • several source systems or company files;
  • unreconciled financials;
  • poor inventory accuracy;
  • many years of detailed history;
  • complex multi-entity operations;
  • custom integrations;
  • extensive custom development;
  • unclear requirements;
  • compressed timeline;
  • limited internal availability.

The cheapest proposal is not always the lowest-cost migration. An incomplete project can create expensive corrective work after go-live.

QuickBooks to Acumatica Migration Timeline

Migration duration depends on scope.

A basic financial migration with clean data and limited integration requirements can be completed much faster than a multi-entity transformation involving distribution, manufacturing, eCommerce, historical transactions, and several custom integrations.

The timeline normally includes:

  • discovery and scope definition;
  • Acumatica configuration;
  • data cleansing and mapping;
  • test migration;
  • integration configuration or development;
  • reporting;
  • testing;
  • training;
  • final migration;
  • go-live stabilization.

Factors That Shorten the Timeline

  • clean data;
  • clear process ownership;
  • standard requirements;
  • existing connectors;
  • available decision-makers;
  • limited historical migration;
  • phased implementation.

Factors That Extend the Timeline

  • multiple entities;
  • complex data;
  • full transaction history;
  • custom development;
  • many integrations;
  • manufacturing or construction complexity;
  • delayed approvals;
  • insufficient testing resources;
  • changing project scope.

A responsible implementation partner should provide milestones and dependencies rather than promising one universal duration.

Common QuickBooks to Acumatica Migration Mistakes

Mistake 1: Migrating Dirty Data

Importing duplicates, obsolete items, incorrect addresses, and unreconciled balances creates immediate distrust in the new ERP.

Mistake 2: Recreating QuickBooks Limitations

The company should not copy every old account, class, spreadsheet, and workaround into Acumatica.

The new system should support the future operating model.

Mistake 3: Skipping a Full Test Migration

Sample imports are useful, but the company should complete at least one realistic migration rehearsal with reconciliation before cutover.

Mistake 4: Migrating Too Much History Without a Business Reason

Full historical detail can increase cost and risk without creating equal value.

Mistake 5: Ignoring Integrations Until the End

Integrations influence customers, items, warehouses, taxes, payments, order types, and posting logic. They must be part of the initial architecture.

Mistake 6: Underestimating Inventory

Inventory migration requires agreement between quantities, values, warehouses, units, lots, serials, and the general ledger.

Mistake 7: Insufficient User Involvement

Users should participate in discovery, testing, training, and cutover approval.

Mistake 8: Rushing Financial Reconciliation

The trial balance alone is not enough. AR, AP, inventory, cash, projects, and open documents must also be validated.

Mistake 9: No Cutover or Rollback Plan

The company needs defined transaction freeze timing, backups, responsibilities, validation steps, and contingency decisions.

Mistake 10: No Post-Go-Live Support Plan

Users and integrations need active support during the first production cycles.

Industry-Specific QuickBooks to Acumatica Migration Considerations

Acumatica vs QuickBooks for Distribution

Distribution businesses often outgrow QuickBooks because inventory, purchasing, sales orders, warehouses, fulfillment, eCommerce, and financials are spread across several tools.

A distribution migration may include:

  • inventory items and classes;
  • multiple warehouses and locations;
  • sales and purchase orders;
  • customer-specific pricing;
  • vendor relationships;
  • replenishment rules;
  • shipping integrations;
  • EDI;
  • returns;
  • margin and inventory reporting.

The Acumatica target design should establish one source of truth for order-to-cash, procure-to-pay, inventory, and warehouse workflows.

Acumatica vs QuickBooks for Manufacturing

QuickBooks Enterprise can support manufacturing and wholesale scenarios, but growing manufacturers may require a more connected production environment.

An Acumatica manufacturing migration may involve:

  • items and units of measure;
  • bills of material;
  • routing;
  • work centers;
  • production orders;
  • material requirements planning;
  • work in process;
  • labor and overhead;
  • job costing;
  • engineering changes;
  • shop-floor data;
  • production and financial reconciliation.

Manufacturing data usually requires design work beyond direct QuickBooks field mapping.

Acumatica vs QuickBooks for Construction

Construction companies may need to connect accounting with projects, commitments, change orders, billing, retainage, field activity, payroll, and document workflows.

Migration considerations may include:

  • projects and jobs;
  • cost codes and account groups;
  • budgets;
  • commitments;
  • subcontracts;
  • change orders;
  • project billing;
  • open receivables and payables;
  • retainage;
  • field and office workflows;
  • project history.

The company should decide whether active projects will be migrated in detail or introduced with approved opening positions.

Acumatica vs QuickBooks for eCommerce

An eCommerce business may use QuickBooks primarily for accounting while product, order, inventory, payment, warehouse, and fulfillment data are managed elsewhere.

The migration must connect:

  • products and variants;
  • SKUs;
  • prices;
  • customers;
  • orders;
  • taxes;
  • payments;
  • warehouses;
  • inventory availability;
  • shipments;
  • tracking;
  • returns;
  • refunds;
  • channel profitability.

BizTech’s proprietary commerce and marketplace connectors can reduce the need to develop each integration from the beginning.

Acumatica vs QuickBooks for Multi-Entity Businesses

A multi-entity migration may require:

  • company and branch architecture;
  • account and subaccount design;
  • shared master data;
  • intercompany transactions;
  • currency handling;
  • consolidated reporting;
  • security separation;
  • migration from several company files;
  • entity-by-entity reconciliation.

This is often a transformation project rather than a simple accounting migration.

Why Work with BizTech for QuickBooks to Acumatica Migration?

BizTech is an Acumatica Gold Partner with experience in ERP implementation, data migration, customization, reporting, automation, integrations, training, testing, and post-go-live support.

Our migration approach combines functional and technical work.

BizTech can help with:

  • QuickBooks environment assessment;
  • business process discovery;
  • Acumatica solution architecture;
  • chart of accounts redesign;
  • customer, vendor, and item migration;
  • open AR and AP migration;
  • inventory reconciliation;
  • historical data strategy;
  • custom Acumatica development;
  • eCommerce and marketplace integrations;
  • payment and warehouse integrations;
  • reports and dashboards;
  • user acceptance testing;
  • role-based training;
  • final cutover;
  • ongoing support.

BizTech also develops proprietary Acumatica solutions. This matters because many companies moving from QuickBooks have already built a complex connected application environment.

Instead of replacing QuickBooks and leaving every other system disconnected, BizTech can help design Acumatica as the central ERP behind commerce, marketplaces, warehouses, payments, CRM, EDI, and custom platforms.

According to the BizTech website, the company is an Acumatica Gold Partner with more than 500 successful integrations and experience supporting businesses across more than 35 countries.

The practical advantage is one accountable partner for implementation and integration.

Why Partner Capability Matters

A migration partner should understand:

  • accounting;
  • operations;
  • inventory;
  • data transformation;
  • Acumatica configuration;
  • API integration;
  • testing;
  • training;
  • go-live support.

A company that only understands data import may miss operational design.

A company that only understands accounting may miss integration architecture.

A company that only writes code may miss financial controls and business process requirements.

BizTech combines these disciplines in one Acumatica practice.

Final QuickBooks to Acumatica Migration Checklist

Before go-live, confirm the following.

Business and Scope

  • Project objectives are documented.
  • In-scope Acumatica applications are approved.
  • Process owners are assigned.
  • Required integrations are identified.
  • Change requests are controlled.

Configuration

  • Companies and branches are configured.
  • Chart of accounts and subaccounts are approved.
  • Customers, vendors, and item classes are configured.
  • Warehouses and locations are configured.
  • Order types and numbering sequences are configured.
  • Taxes, terms, currencies, and payment methods are validated.
  • Security roles are tested.

Data

  • Duplicate records are resolved.
  • Inactive records are reviewed.
  • Opening balances are reconciled.
  • AR and AP aging are reconciled.
  • Inventory quantity and value are reconciled.
  • Open sales and purchase orders are validated.
  • Historical data strategy is approved.
  • Final migration files are controlled.

Integrations

  • Credentials are validated.
  • Items, customers, warehouses, payments, taxes, and carriers are mapped.
  • Orders are tested.
  • Inventory synchronization is tested.
  • Fulfillment and tracking are tested.
  • Returns and refunds are tested.
  • Error handling, retries, and logs are tested.
  • Production schedules and webhooks are approved.

Reporting

  • Financial statements are validated.
  • Management dashboards are ready.
  • Operational reports are approved.
  • Security restrictions are tested.
  • Legacy comparative reporting is addressed.

Users

  • Users are created.
  • Roles and permissions are tested.
  • Role-based training is complete.
  • Documentation is available.
  • Support contacts and escalation paths are communicated.

Cutover

  • Transaction freeze timing is approved.
  • QuickBooks backups are complete.
  • Final extraction responsibility is assigned.
  • Final reconciliation steps are documented.
  • Go-live approval criteria are defined.
  • Rollback and contingency decisions are documented.
  • Post-go-live support coverage is active.

Final Conclusion: Moving from QuickBooks to Acumatica

QuickBooks can support a business successfully for many years.

Moving away from it should not be treated as a criticism of the software or a mandatory milestone tied to revenue. The decision should be based on whether the current system environment still supports the company’s operational complexity, reporting needs, integrations, and growth strategy.

The strongest signs that a migration is needed are usually not accounting failures.

They are operational fragmentation, manual work, delayed visibility, disconnected inventory, complex consolidations, unreliable integrations, and an increasing dependence on spreadsheets and separate applications.

Acumatica provides a path from an accounting-centered environment to a connected cloud ERP platform.

A successful QuickBooks to Acumatica migration can give the business:

  • one source of truth;
  • connected financial and operational data;
  • real-time inventory visibility;
  • automated workflows;
  • broader user access;
  • industry-specific functionality;
  • integrated eCommerce and marketplaces;
  • stronger dashboards and reporting;
  • open APIs and future flexibility;
  • a scalable platform for growth.

But those benefits do not come from a basic data import.

They require business discovery, target architecture, data cleansing, configuration, integration, reconciliation, testing, training, cutover planning, and ongoing support.

As an Acumatica Gold Partner, BizTech helps businesses manage the complete transition from QuickBooks to Acumatica. Our team can migrate data, implement Acumatica applications, build custom functionality, connect external platforms, validate financials and inventory, train users, and support the new environment after go-live.

For companies searching for:

  • QuickBooks to Acumatica Migration;
  • Acumatica vs QuickBooks;
  • QuickBooks Enterprise Alternative;
  • QuickBooks Online to Acumatica Migration;
  • QuickBooks Desktop to Acumatica Migration;
  • QuickBooks to ERP Migration;
  • Acumatica Data Migration Services;
  • Acumatica Implementation Partner;
  • Acumatica Gold Partner;
  • BizTech Acumatica Migration;

the next step is a structured migration assessment.

QuickBooks provides the starting data.

Acumatica provides the connected ERP platform.

BizTech helps build the path between them.

FAQ: QuickBooks to Acumatica Migration

Can QuickBooks data be migrated to Acumatica?

Yes. Customers, vendors, inventory items, chart of accounts, opening balances, open AR and AP documents, sales and purchase orders, projects, and selected historical transactions can be migrated. Exact scope depends on the QuickBooks product, data quality, Acumatica configuration, and business requirements.

Can QuickBooks Online be migrated to Acumatica?

Yes. QuickBooks Online data can be exported, transformed, and imported into Acumatica. Connected applications and data stored outside QuickBooks Online must also be assessed.

Can QuickBooks Desktop Enterprise be migrated to Acumatica?

Yes. QuickBooks Enterprise can be migrated, including financials, customers, vendors, inventory, open transactions, and selected history. Advanced inventory, manufacturing, job costing, multi-company, and connected application workflows may require additional design.

Is Acumatica better than QuickBooks?

They serve different levels of complexity. QuickBooks is a strong accounting platform with capabilities that vary by edition. Acumatica is a complete cloud ERP platform designed to connect accounting with inventory, distribution, manufacturing, construction, projects, CRM, eCommerce, reporting, and automation.

When should a business move from QuickBooks to Acumatica?

A business should evaluate migration when disconnected systems, manual work, multiple entities, inventory complexity, slow reporting, integration failures, eCommerce growth, manufacturing, construction, or project requirements exceed the practical fit of the existing QuickBooks environment.

How long does a QuickBooks to Acumatica migration take?

Timeline depends on scope, data quality, entities, history, modules, integrations, customization, testing, and user availability. A basic financial migration can be much shorter than a multi-entity distribution, manufacturing, construction, or eCommerce transformation.

How much does QuickBooks to Acumatica migration cost?

Cost depends on Acumatica applications, implementation, data migration, integrations, customization, reporting, training, testing, and support. A discovery and data assessment are required for a reliable estimate.

Can historical QuickBooks transactions be migrated?

Yes, but the business should choose between full detailed migration, limited history, or opening balances with a legacy archive. Full history increases cost, transformation, testing, and reconciliation effort.

Can QuickBooks inventory be migrated to Acumatica?

Yes. Items, SKUs, units of measure, warehouses, quantities, costs, prices, vendors, and other inventory information can be migrated. Quantities and values should be reconciled before final cutover.

Can open QuickBooks invoices and bills be migrated?

Yes. Open customer invoices, vendor bills, credits, unapplied payments, deposits, due dates, and remaining balances can be imported and reconciled in Acumatica.

Should we keep QuickBooks after Acumatica goes live?

Some companies retain QuickBooks temporarily or as a historical archive. The decision depends on history migration, audit requirements, licensing, data retention, and whether users need direct access to legacy transactions.

Can Acumatica connect to our Shopify, WooCommerce, Amazon, or Magento store?

Yes. BizTech develops Acumatica connectors for Shopify, WooCommerce, Amazon FBA/FBM, Magento, and other commerce environments. These integrations can support orders, inventory, customers, products, payments, fulfillment, tracking, returns, and refunds.

Can BizTech migrate our company from QuickBooks to Acumatica?

Yes. BizTech is an Acumatica Gold Partner providing process discovery, Acumatica implementation, QuickBooks data migration, reconciliation, integrations, customization, reporting, training, cutover, and post-go-live support.

Why choose an Acumatica Gold Partner for migration?

A qualified Gold Partner combines Acumatica platform expertise with implementation, data migration, integration, testing, training, and long-term support. This reduces the risk of treating the project as a simple file conversion.

[/vc_column_text][/vc_column][/vc_row]

The post QuickBooks to Acumatica Migration Guide 2026 | Complete ERP Transition Guide appeared first on Biz-Tech Services.

]]>