Required fields the source never sends: subsidiary, department, class and posting groups

Fields that exist only on the ERP side

A store order describes a sale: a customer, lines, a shipping address, a payment. An ERP order also describes where the sale lands in the books. That second part has fields the store has never heard of.

Shopify's order has no subsidiary, no department, no class and no posting group. It does have sourceName ("web", "pos"), discountCodes, a shippingLine, a poNumber for business customers and a customer that is null for a guest checkout. Everything the ERP needs beyond that has to be derived.

What the two most common US mid-market ERPs ask for, read from NetSuite's Records Browser and Microsoft's Business Central reference on October 3, 2026:

In NetSuite's schema department, class and location are optional. In many accounts they are not: the accounting preferences Make Departments Mandatory, Make Classes Mandatory and Make Locations Mandatory turn them into required fields for every transaction, and custom segments have their own Mandatory option. Oracle's documentation names the consequence for other processes too, such as a currency revaluation that fails when a source transaction lacks a required segment. An integration that worked in a sandbox without those preferences starts failing on the first production order.

Worked example: one order, six derived values

Order 1052 comes from the online store, ships to Ohio and is assigned to the Reno warehouse. It has 3 lines with a subtotal of 480.00, discount code SPRING10 for 10% and an automatic discount of 15.00.

The rules for this account:

The discount needs arithmetic. 10% of 480.00 is 48.00. With the automatic 15.00 that is 48.00 + 15.00 = 63.00 in total, and the order total before tax and shipping is 480.00 - 63.00 = 417.00. The sales order header holds one discountitem and one discountrate. Written as one header discount of -63.00, the total is right and the information which code gave what is lost. Written as two discount lines, each below the lines it applies to, both survive, and so does the split per line that revenue reports by class or department need.

The item map and the items no product has

The store knows a product by its variant ID and SKU, NetSuite by an internal ID. The item map is the table between them, and it has to be kept: a new variant in Shopify has no row until someone or something adds it. An order line for a variant without a row has no item, and the order cannot be saved.

Standard connectors and iPaaS platforms document a second gap. Their item map covers products that exist in the store, and transaction-only items are not created by it: discount items, shipping items and refund adjustment items have to be created in NetSuite and mapped by hand. The same guidance warns that an item without a map record is skipped by the inventory sync without an error.

Posting groups in Business Central

Business Central decides the G/L accounts of a sale through posting groups. The customer carries a Customer Posting Group for the receivables account and a Gen. Bus. Posting Group that, combined with the item's Gen. Prod. Posting Group, picks the sales account. For US sales tax the customer has a Tax Area Code and Tax Liable, and the item a Tax Group Code.

The standard API v2.0 customer resource exposes taxLiable, taxAreaId, paymentTermsId, shipmentMethodId and paymentMethodId, and no posting group. A customer created through it gets its posting groups from setup inside Business Central. If that setup is missing, the order is saved and the invoice cannot be posted, which is found days later by whoever runs the posting. So the integration checks before go-live that every customer it creates ends up with a posting group, and the dry run posts a test invoice for each customer type.

Defaults that hide errors

A default is the right answer for a field with no source. It is also the easiest way to make a wrong value invisible: every order lands, and the department report is wrong for a quarter.

Three rules keep defaults honest:

• A default is used only for a field that has no source at all. A field with a source but no matching row in the lookup table, such as a new sales channel or a new warehouse, goes to the review list instead of to the default.
• Every derived value is logged with the rule that produced it, so a report can be traced back to the order.
• A change in the ERP's preferences, such as a newly mandatory class, shows up as a failed dry run before it shows up as failed orders.

Standard connector guidance names the same risk on the customer side: when the subsidiary on a customer does not match the expected value, the import fails or creates a duplicate customer. How duplicates come about is covered in duplicate customers and duplicate orders.

What this means for your integration

We list every field your ERP requires, including the ones your accounting preferences made mandatory, and write a rule for each: derived from a store field, looked up in a table, or a default for fields with no source. New channels, warehouses and products that have no row yet go to the review list instead of to a default, and every order in the log shows which rule set which value.

Required fields are one part of the field mapping of an order. The order flow is on orders, customers and shipping and the NetSuite side on the NetSuite integration page. Send us an export of a few orders and your ERP's required fields, and we show which values the store can give and which need a rule.