NetSuite TMS Integration: LTL & Hazmat Options

Manual LTL shipment setup eats hours every week. You're copying carrier details, calculating freight costs, and re-entering data that should flow automatically. If you ship HAZMAT, the stakes are higher: one mislabeled class or UN number can stop a shipment at the dock.

Here's what actually works for NetSuite TMS integration, which vendors to screen carefully, and how to structure your HAZMAT data before you connect anything.

Why LTL Is the Hardest Integration

Most TMS providers built their platforms around parcel shipping first. Parcel carriers (UPS, FedEx) have standardized APIs, predictable rate tables, and uniform label formats. LTL is different.

LTL freight depends on the carrier. Each one has its own accessorial charges, liftgate requirements, residential delivery fees, and HAZMAT handling rules. A TMS that handles parcel brilliantly can fall apart on LTL because the carrier integration depth isn't there.

Before you evaluate vendors, answer three questions:

1. How many carriers do you use for LTL? More carriers means you need a TMS with mature carrier connections, not just a generic REST API.
2. Do you post loads to DAT or other load boards? Some TMS platforms handle this natively; others don't.
3. Who audits your freight invoices? If you're not auditing, you're likely overpaying. Your TMS should support invoice auditing against contracted rates.

TMS Options Worth Evaluating

The NetSuite community consistently names ShipHawk, FreightPOP, and Pacejet as the leading TMS integrations. Here's the honest breakdown:

Vendors to screen carefully: Elemica and Uber Freight have drawn repeated negative feedback from NetSuite practitioners. Pacejet and RF-SMART get mixed reviews. That doesn't mean they're wrong for you, but it means you need to validate their LTL and HAZMAT capabilities with your actual carrier contracts.

The HAZMAT Data Problem

Here's where most integrations break: your HAZMAT data isn't structured in NetSuite.

A TMS can only send what it receives. If your dangerous goods information lives in SDS binders, spreadsheets, or a separate compliance system, the integration will fail at the first shipment.

Step 1: Set up Item Classes and Groups correctly.

Classes in NetSuite are categories you create to track records such as financials, transactions, and employees. They also let you organize items for filtering and reporting. Go to Setup > Accounting > Classes and create classes that map to your HAZMAT categories. For example:

• HAZ-Flammable
• HAZ-Corrosive
• HAZ-Oxidizer

Then assign items to these classes. This gives you a filterable data set that both NetSuite and your TMS can read. The internal ID for this record is classification, which matters when you map fields in your integration.

Step 2: Store HAZMAT fields on the item record.

Create custom fields on the item record for:

• UN number
• Hazard class
• Packing group
• Proper shipping name
• Flash point (if applicable)

These fields become the payload your TMS receives. If they're empty, your integration has nothing to work with. The SuiteTalk REST Web Services Records Guide documents how these custom fields appear in API payloads, which helps when you're mapping them to TMS fields.

Step 3: Test with a single record first.

Create one HAZMAT item with complete data. Run it through your TMS test environment. Verify the label output, the carrier's HAZMAT acceptance, and the documentation generation. Then scale to your full catalog.

This is where most integrations break. The TMS connection works. The data feeding it doesn't.

Integration Architecture Options

You have three realistic paths for connecting NetSuite to a TMS:

1. Native SuiteApp

Vendors like FreightPOP and ShipHawk offer SuiteApps listed on NetSuite's SuiteApp marketplace. These use NetSuite Connector or custom RESTlets to sync data.

Pros: Faster deployment, vendor-managed maintenance, built-in field mappings. Cons: You're locked into the vendor's integration design. Customization requires their development team.

2. REST API with Custom Integration

Most TMS platforms expose REST APIs. You build the integration using SuiteScript 2.1, typically with:

• N/https module for outbound requests
• N/record module to read shipment data
• N/query (SuiteQL) to pull item and order details

The SuiteScript Records Guide documents the shipment record type and its supported operations. Here's a minimal example of pushing a shipment to a TMS endpoint:

/**
 * @NApiVersion 2.1
 * @NScriptType ScheduledScript
 */
define(['N/https', 'N/record', 'N/log'], (https, record, log) => {
    const execute = (context) => {
        const shipmentId = context.shipmentId;
        const shipmentRecord = record.load({
            type: record.Type.SHIPMENT,
            id: shipmentId
        });

        const payload = {
            shipmentId: shipmentRecord.id,
            shipDate: shipmentRecord.getValue({ fieldId: 'shipdate' }),
            carrier: shipmentRecord.getValue({ fieldId: 'carrier' }),
            hazmat: shipmentRecord.getValue({ fieldId: 'custbody_hazmat_class' })
        };

        const response = https.post({
            url: 'https://your-tms-endpoint.com/api/shipments',
            headers: {
                'Authorization': 'Bearer ' + getAccessToken(),
                'Content-Type': 'application/json'
            },
            body: JSON.stringify(payload)
        });

        if (response.code !== 200) {
            log.error('TMS Push Failed', response.body);
            // Trigger retry logic here
        }
    };

    return { execute };
});

Pros: Full control, no per-transaction fees, tailored to your exact workflow. Cons: You own the maintenance. API changes on the TMS side break your integration until you update it.

3. Middleware / iPaaS

Tools like Celigo, Boomi, or Workato sit between NetSuite and the TMS.

Pros: Visual mapping, pre-built connectors, easier error handling. Cons: Monthly subscription cost, another system to monitor, still requires configuration work.

The Integration Design Conversation

Before you sign with any TMS vendor, sit down with your finance and operations teams together. The most common failure isn't technical. It's that finance wants invoice data and operations wants shipment visibility, and neither team agreed on the data flow.

Decide:

• Which system owns shipment status? The TMS should be the source of truth for tracking; NetSuite owns the financial record.
• How often does data sync? Real-time integrations give visibility but require more infrastructure. A 15-minute polling interval works for most LTL operations.
• Who handles errors? When a shipment fails to push, does ops retry it or does finance? Define this before go-live.

Validation: Proving the Integration Works

Here's the validation step after you've connected your TMS:

1. Create a test sales order with a HAZMAT item.
2. Fulfill the order and generate the shipment record.
3. Confirm the TMS received the shipment with all HAZMAT fields populated.
4. Verify the carrier's rate quote matches your contracted rate.
5. Generate the bill of lading and HAZMAT documentation.
6. Confirm the freight invoice flows back to NetSuite for audit.

If any step fails, the error response tells you exactly what went wrong. Check whether it's a field mapping issue, a missing data point, or a carrier rejection.

What to Check Next

If you're still manually setting up LTL shipments, the TMS selection matters less than your data readiness. Get your HAZMAT classes and item fields structured first. Then evaluate vendors against your carrier list, not against marketing claims.

The CSV Imports Guide is worth reviewing here. If you have hundreds of items needing class assignments or custom field values, a CSV import is often faster than editing records one by one. You can export your item list, populate the HAZMAT fields in a spreadsheet, and import the changes back in bulk.

A clean item master makes any TMS integration dramatically easier to configure and maintain. Once your data structure is solid, the vendor selection becomes a much simpler conversation.