How to Automate Shipment Status Updates from 3PL to ERP and Customer Notification

To automate shipment status updates from a 3PL to your ERP and customers, eZintegrations connects to your 3PL’s tracking API (DHL, UPS, FedEx, or 3PL-specific platforms like Kenco, Ryder, or XPO) or SFTP tracking feed, ingests shipment events in real time or on a configurable schedule, updates the corresponding delivery or transfer order in SAP S/4HANA or NetSuite with the current status (in transit, out for delivery, delivered), triggers the goods receipt confirmation in the ERP when the delivery status changes to Delivered, and sends an automated customer notification (email or SMS) at each key milestone: Shipped, Out for Delivery, and Delivered. The full flow runs without manual intervention from your operations or customer service team.

---

TL;DR

• When a 3PL ships an order, three things need to happen: the ERP needs to know (to update delivery status, trigger invoicing, and post goods receipt), the customer needs to know (to set expectations, reduce inbound enquiries, and build trust), and your ops team needs visibility (to manage exceptions and SLA compliance). All three currently require manual steps at most companies.
• eZintegrations connects to 3PL tracking APIs or SFTP feeds (DHL, UPS, FedEx, Kenco, Ryder, XPO, and others), maps the shipment events to ERP records, updates the ERP delivery status via API, posts goods receipts when delivery is confirmed, and sends customer notifications at key milestones.
• Level 1 (iPaaS Workflows) handles 3PL API polling or webhook receipt, shipment event parsing, ERP delivery record lookup and update, goods receipt posting, and customer notification sending. Level 2 (AI Workflows) matches incoming tracking references to ERP sales orders or delivery documents (handling cases where the 3PL tracking number does not directly match an ERP reference), detects delivery exceptions (failed delivery attempts, customs holds, address corrections needed), and classifies delay severity. Level 3 (AI Agents) monitors in-transit shipments for SLA compliance, proactively identifies shipments at risk of missing promised delivery dates, generates exception reports for the customer service team, and detects patterns in 3PL delivery performance. Level 4 (Goldfinch AI) provides the Goldfinch AI Chat UI as a Workflow Node: “Which shipments are currently delayed beyond their promised delivery date?”, “What is our on-time delivery rate this month by 3PL?”, or “Which customers have not yet received their shipment from last week?”
• Works with DHL, UPS, FedEx, Kenco, Ryder, and XPO on the 3PL side, and SAP S/4HANA, NetSuite, Microsoft Dynamics 365, and Oracle on the ERP side.
• Configuration time: 2-4 days per 3PL-ERP pair.

---

The 3PL Visibility Gap: When Your Customer Knows Less Than They Should

It is 2:30 PM on a Thursday. Your customer service representative Sarah has received four messages today asking the same question: “Where is my order?”

Your 3PL shipped those orders on Tuesday. The tracking numbers are in your 3PL’s portal. But they are not in your ERP. They are not in your CRM. They have not been emailed to the customers. Sarah has to log into the DHL portal, search each tracking number manually, copy the status, and paste it into a reply email. Four customers. Four manual lookups. Fifteen minutes per reply.

Meanwhile, your ERP still shows those four sales orders as “In Delivery.” The goods receipt has not been posted. The invoicing run that triggers when orders are delivered will not run until someone posts the receipt. Finance is waiting for the invoice trigger. The customer is waiting for their order status. And the 3PL delivered two of the four orders yesterday.

Finance noticed on Monday that an order from the prior week had not been invoiced. Investigation revealed the goods receipt was never posted because nobody saw the delivery confirmation in the DHL portal.

This is the 3PL visibility gap – a common challenge in logistics operations highlighted in Gartner research on transportation and supply chain visibility. Your 3PL has the data. Your ERP needs the data. Your customers need the data. Manual processes in the middle mean all three are operating with stale or missing information.

---

The Three Data Flows That Must Happen After a Shipment

When a 3PL marks an order as shipped (or picks up from the warehouse and generates a tracking number), three separate data flows need to happen:

Flow 1: ERP update. The sales order or delivery document in the ERP needs to reflect the current shipment status: Shipped, In Transit, Out for Delivery, Delivered, or Exception. When the status reaches Delivered, the goods receipt needs to be posted (for inbound shipments) or the outbound delivery confirmed (for sales orders), triggering the invoice generation.

Flow 2: Customer notification. The end customer needs to know their order has shipped (with tracking number), when it is out for delivery, and when it has been delivered. These notifications reduce inbound customer service enquiries, build trust, and improve delivery experience outcomes.

Flow 3: Exception visibility. When a shipment encounters a problem (failed delivery attempt, customs hold, weather delay, address correction needed), the customer service team and the account manager need to know immediately, not after the customer calls.

All three flows start with the same trigger: a tracking event from the 3PL, reflecting broader shifts toward real-time visibility in modern digital supply chains.

---

Connecting to 3PL Tracking Data: APIs, Webhooks, and SFTP Feeds

Each 3PL exposes tracking data differently. The integration architecture depends on which method the 3PL supports.

Method 1: Real-Time Webhook/Push Notification

The 3PL pushes tracking events to eZintegrations as they occur. This is the most real-time and lowest-latency method.

DHL, UPS, and FedEx all support event-driven webhook notifications when you register a tracking number for notification:

• DHL: POST /tracking/v2/webhook to register, events POSTed to your endpoint
• UPS: Quantum View Notify or the UPS Track API webhook subscription
• FedEx: FedEx Tracking API POST /track/v1/trackingdocuments/subscribeeventids with a callback URL

When a tracking event fires (e.g., “Out for Delivery”), the 3PL posts the event payload to eZintegrations instantly.

Method 2: REST API Polling (Pull)

For 3PLs that do not support push webhooks, eZintegrations polls their tracking API on a configurable schedule (every 15-30 minutes for high-priority shipments, hourly for standard).

Method 3: SFTP Tracking Feed

Regional 3PLs and warehouse management systems often publish tracking files to an SFTP location on a schedule (hourly or every few hours). eZintegrations monitors the SFTP, downloads new files, parses them, and processes the tracking events.

Method 4: EDI 214 Transportation Carrier Shipment Status Message

In EDI-connected supply chains, transportation status updates are delivered as ANSI X12 EDI 214 transactions. eZintegrations parses EDI 214 documents and converts them to structured tracking events.

---

DHL Tracking API: Real-Time Event Ingestion

DHL Express provides a REST tracking API for real-time shipment status:

Register for tracking webhook notifications:

POST https://api-eu.dhl.com/track/shipments
Authorization: apikey {dhl_api_key}
Content-Type: application/json

{
  "shipmentTrackingNumber": "{dhl_tracking_number}",
  "service": "express",
  "requesterCountryCode": "US",
  "originCountryCode": "US",
  "destinationCountryCode": "GB"
}

Or poll for current status:

GET https://api-eu.dhl.com/track/shipments
    ?trackingNumber={dhl_tracking_number}
Authorization: apikey {dhl_api_key}

DHL tracking event response structure:

{
  "shipments": [{
    "id": "{dhl_tracking_number}",
    "service": "express",
    "status": {
      "timestamp": "2026-03-14T09:42:00",
      "location": { "address": { "addressLocality": "London Heathrow", "countryCode": "GB" }},
      "status": "in-transit",
      "description": "Arrived at DHL facility",
      "remark": "On vehicle for delivery"
    },
    "events": [
      {
        "timestamp": "2026-03-14T09:42:00",
        "location": { "address": { "addressLocality": "London", "countryCode": "GB" }},
        "status": "out-for-delivery",
        "description": "With delivery courier"
      }
    ],
    "estimatedTimeOfDelivery": "2026-03-14T18:00:00"
  }]
}

The status field maps to ERP delivery status values:

• pre-transit → ERP: Planned
• transit → ERP: In Transit
• out-for-delivery → ERP: Out for Delivery (trigger customer notification)
• delivered → ERP: Delivered (trigger goods receipt posting + customer notification)
• delivery-failure → ERP: Delivery Exception (trigger alert to CS team)

---

UPS Tracking API: Webhook and REST Polling

UPS provides two tracking integration methods: the UPS Track API (REST) and Quantum View Notify (QVN) for push notifications.

UPS Track API (polling):

GET https://onlinetools.ups.com/api/track/v1/details/{tracking_number}
    ?locale=en_US&returnSignature=false
Authorization: Bearer {ups_oauth_token}

UPS OAuth 2.0 authentication:

POST https://onlinetools.ups.com/security/v1/oauth/token
Authorization: Basic {base64(client_id:client_secret)}
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

UPS tracking event response:

{
  "trackResponse": {
    "shipment": [{
      "inquiryNumber": "{tracking_number}",
      "package": [{
        "currentStatus": { "code": "011", "simplifiedText": "Delivered" },
        "deliveryDate": [{ "type": "DEL", "date": "20260314" }],
        "deliveryTime": { "endTime": "143200" },
        "activity": [
          {
            "date": "20260314",
            "time": "143200",
            "status": { "code": "011", "description": "Delivered" },
            "location": { "address": { "city": "Austin", "stateProvince": "TX", "countryCode": "US" }}
          }
        ]
      }]
    }]
  }
}

UPS status codes relevant to ERP update triggers:

• 003: Pickup (In Transit)
• 022: Out for Delivery
• 011: Delivered (trigger goods receipt)
• 007: Delivery Exception (trigger alert)

---

Kenco and Regional 3PL: SFTP and EDI 214 Status Updates

Kenco Group and other regional 3PL providers typically provide tracking data via SFTP file exports or EDI 214 transactions rather than REST APIs.

SFTP CSV Tracking Feed (Kenco / Regional 3PL)

Kenco publishes shipment status files to an SFTP location every hour:

SFTP: sftp.kenco.com/outbound/tracking/
File format: tracking_YYYYMMDD_HHMMSS.csv

CSV structure:

ORDER_NUMBER,TRACKING_NUMBER,CARRIER,STATUS,TIMESTAMP,LOCATION,ESTIMATED_DELIVERY
SO-2026-0441,1Z999AA10123456784,UPS,OUT_FOR_DELIVERY,2026-03-14 09:15:00,Austin TX,2026-03-14
SO-2026-0442,1Z999AA10123456785,UPS,DELIVERED,2026-03-14 11:47:00,Houston TX,
SO-2026-0443,1254789654,FEDEX,IN_TRANSIT,2026-03-14 08:30:00,Memphis TN,2026-03-15

eZintegrations monitors this SFTP location, downloads new files, parses each row, and processes the status events.

EDI 214 Transportation Carrier Shipment Status

For EDI-connected supply chains, status updates arrive as EDI 214 documents:

ISA*00*          *00*          *ZZ*KENCO          *ZZ*MERIDIAN       *260314*1015*U*00401*000000002*0*P*>~
GS*QM*KENCO*MERIDIAN*20260314*1015*2*X*004010~
ST*214*0001~
B10*SO-2026-0441*1254789654*KENCO~
L11*SO-2026-0441*CO~
AT7**OD**0915*0000*20260314*R~
MS3*KENCO*M**~
SE*6*0001~
GE*1*2~
IEA*1*000000002~

Key EDI 214 segments:

• B10: shipment reference number and pro number (tracking)
• AT7: shipment status code (OD = Out for Delivery, D1 = Delivered, X1 = Exception)
• AT8: shipment weight and dimensions

eZintegrations parses the EDI 214 and converts it to a structured tracking event record.

---

Matching Tracking Events to ERP Records

The most technically complex part of 3PL-to-ERP automation is matching the incoming tracking reference to the correct ERP record. The 3PL tracking number is rarely the same as the ERP delivery document number or sales order number.

Matching Strategies

Strategy 1: Store the 3PL tracking number in the ERP when the shipment is created.

When the 3PL creates the shipment, their system sends the tracking number to the ERP via a prior integration (or manually). The tracking number is stored in the ERP delivery document as an external reference field. When the tracking event arrives, eZintegrations queries the ERP by this tracking number.

SAP: find delivery by tracking number:

GET /sap/opu/odata/sap/API_OUTBOUND_DELIVERY_SRV/
    A_OutbDeliveryHeader
    ?$filter=ExternalIdentification eq '{tracking_number}'
    &$select=DeliveryDocument,ShippingPoint,DeliveryDate,
    OverallDelivProcgStatus

NetSuite: find transfer order or fulfilment by tracking number:

SELECT id, tranid, status, shipaddress
FROM transaction
WHERE type = 'ItemShip'
AND (custbody_tracking_number = '{tracking_number}'
     OR externalid = '{tracking_number}')

Strategy 2: Cross-reference via order number.

The 3PL shipment record includes the customer order number or the ERP sales order number (passed when the order was sent to the 3PL). Match on this reference:

-- NetSuite: find fulfillment by customer PO number
SELECT f.id, f.tranid, f.status
FROM transaction f
WHERE f.type = 'ItemShip'
AND f.custbody_customer_po = '{order_number_from_3pl}'

Strategy 3: Level 2 fuzzy matching.

When neither the tracking number nor the order number produces a direct match (common when the 3PL reference format differs from the ERP format), Level 2 applies fuzzy matching: company name + address + approximate order value + approximate ship date, querying the ERP for candidates and selecting the best match above a confidence threshold.

---

ERP Delivery Status Update: SAP, NetSuite, Dynamics 365

SAP S/4HANA Outbound Delivery Update

When a tracking event arrives, update the SAP outbound delivery:

Update overall delivery status:

PATCH /sap/opu/odata/sap/API_OUTBOUND_DELIVERY_SRV/
    A_OutbDeliveryHeader('{delivery_document}')
Content-Type: application/json

{
  "GoodsIssueOrGoodsReceiptSlipDate": "{event_date}",
  "OverallDelivProcgStatus": "C"
}

For posting goods issue (outbound delivery confirmation) when the delivery event is “Delivered”:

POST /sap/opu/odata/sap/API_OUTBOUND_DELIVERY_SRV/
    PostGoodsIssue
{
  "DeliveryDocument": "{delivery_document}",
  "DeliveryDocumentItem": "000010",
  "ActualGoodsMovementDate": "{delivered_date}"
}

Goods issue posting triggers the accounting document (COGS posting), the transfer to billing due list, and the availability for invoice creation.

NetSuite Item Fulfilment Status Update

For NetSuite outbound shipments (item fulfilment records):

PATCH /services/rest/record/v1/itemFulfillment/{internal_id}
{
  "shipStatus": "C",
  "actualShipDate": "{ship_date}",
  "trackingNumbers": { "items": [{
    "trackingnumber": "{tracking_number}",
    "trackingnumbertype": { "id": "UPS" }
  }]}
}

For inbound shipments (purchase order receipts): when the 3PL confirms delivery of an inbound shipment, post the item receipt in NetSuite:

POST /services/rest/record/v1/itemReceipt
{
  "createdFrom": { "id": "{purchase_order_id}", "type": "purchaseOrder" },
  "tranDate": "{delivery_date}",
  "location": { "id": "{receiving_warehouse_id}" },
  "item": { "items": [{
    "item": { "id": "{item_id}" },
    "quantity": {received_quantity},
    "itemReceive": true
  }]}
}

Microsoft Dynamics 365 Delivery Update

PATCH https://{tenant}.dynamics.com/data/SalesOrderLines
    ?$filter=SalesOrderNumber eq '{so_number}' 
    and ItemNumber eq '{item_number}'
Content-Type: application/json

{
  "DeliveryStatus": "Delivered",
  "ConfirmedDeliveryDate": "{delivery_date}",
  "ShipmentTrackingNumber": "{tracking_number}"
}

---

Goods Receipt Posting: Closing the Loop in the ERP

The goods receipt (or goods issue confirmation for outbound shipments) is the ERP event that triggers downstream processes: invoicing, inventory updates, and financial postings.

The critical timing issue: without automated goods receipt posting, there is always a delay between when the 3PL delivers the shipment and when the ERP reflects it. In manual processes, this delay averages 1-3 days. During this window:

• Inventory counts are inaccurate (the ERP shows stock still in transit)
• Invoicing cannot proceed (the billing due list does not include the order)
• Financial statements are understated (the COGS and revenue are not yet posted)

eZintegrations posts the goods receipt the moment the 3PL confirms delivery.

SAP Goods Receipt for Inbound Shipment

When the 3PL confirms delivery of an inbound purchase order:

POST /sap/opu/odata/sap/API_GOODS_RECEIPT_FOR_PURCHASEORDER_SRV_01/
    ReceiveStorageLocation
{
  "PurchaseOrder": "{po_number}",
  "PurchaseOrderItem": "00010",
  "DocumentDate": "{today}",
  "PostingDate": "{delivery_date}",
  "Material": "{material_number}",
  "Plant": "1000",
  "StorageLocation": "0001",
  "Quantity": "{received_quantity}"
}

SAP posts the goods receipt document (movement type 101), updates the purchase order history, and moves the inventory from “in transit” to “unrestricted use” in the warehouse.

---

Customer Notification: Email and SMS at Each Milestone

Three milestone notifications drive the most value for customer satisfaction:

Milestone 1: Shipped (when the 3PL generates a tracking number and picks up the package) 

Milestone 2: Out for Delivery (when the carrier marks the shipment as out for delivery) 

Milestone 3: Delivered (when the carrier confirms delivery)

Shipment Confirmation Email

Subject: Your order {order_number} has shipped! Tracking: {tracking_number}

Hi {customer_first_name},

Great news: your order from {company_name} is on its way.

Order: {order_number}
Items: {order_line_summary}
Carrier: {carrier_name} | Tracking: {tracking_number}
Estimated delivery: {estimated_delivery_date}

Track your shipment: {tracking_url}

Questions? Reply to this email or call {cs_phone_number}.

{company_name} Customer Service

Out for Delivery Notification

Subject: Your order is out for delivery today!

Hi {customer_first_name},

Your order {order_number} is out for delivery today and should arrive by {estimated_delivery_window}.

Carrier: {carrier_name} | Tracking: {tracking_number}
Track live: {tracking_url}

{company_name}

Delivery Confirmation

Subject: Your order {order_number} has been delivered

Hi {customer_first_name},

Your order {order_number} was delivered on {delivery_date} at {delivery_time}.

If you have any questions about your order, please contact us at {cs_email}.

{company_name}

SMS Notifications (Optional)

For customers who opt into SMS notifications:

• Shipped: “Your order [ORDER] has shipped. Track: [URL]”
• Out for delivery: “Your order [ORDER] is out for delivery today.”
• Delivered: “Your order [ORDER] was delivered. Need help? [CS_URL]”

SMS via Twilio, AWS SNS, or a connected CRM email/SMS platform (Klaviyo, Salesforce Marketing Cloud, HubSpot).

---

Exception Handling: Delays, Failed Deliveries, and Customs Holds

Not every shipment reaches the customer without incident. Level 2 detects four types of exceptions and routes them appropriately.

Exception Type 1: Failed Delivery Attempt

When DHL, UPS, or FedEx marks a delivery as “attempted, no one home” or “delivery exception”:

• Customer notification: “We tried to deliver your order today but were unable to. Your carrier will attempt redelivery on [next attempt date]. To reschedule or arrange collection: [carrier URL].”
• CS team alert: the customer service team receives a flag with the order number, customer name, and carrier reference, allowing proactive outreach.
• ERP status update: delivery document updated to “Exception” status to prevent premature goods receipt posting.

Exception Type 2: Delivery Delay (Beyond Promised Date)

Level 3 monitors every in-transit shipment against its promised delivery date (stored on the ERP sales order). When the estimated delivery date from the carrier exceeds the promised date:

• Internal alert: the account manager and customer service lead receive an alert with the specific delay and the customer’s contact information.
• Customer notification (configurable): for delays beyond 1 business day, a proactive notification can be sent: “We’re sorry, your order [ORDER] has been delayed. Updated estimated delivery: [date].”

Exception Type 3: Customs Hold (International Shipments)

When a DHL or FedEx international shipment enters customs hold:

• Internal alert: the trade compliance team is notified with the shipment reference and the customs clearance status.
• Customer notification: “Your order is currently being processed by customs. This typically takes [X] days. We will notify you when it clears.”

Exception Type 4: Damage or Loss

When the carrier marks a shipment as damaged or lost:

• Internal alert: CS team + account manager + warehouse (to initiate replacement shipment).
• ERP action: delivery document flagged as exception. New order or replacement shipment workflow triggered.

---

Before vs After: Manual 3PL Tracking vs Automated

Process Step	Manual 3PL Tracking Process	Automated with eZintegrations
Customer enquiry trigger	Customer emails “Where is my order?”	Proactive notification before customer asks
Tracking lookup	Manual: log into 3PL portal per shipment	Automated: API or SFTP ingestion
Status visibility	CS team only: no ERP or CRM link	ERP, CRM, and CS team all updated simultaneously
ERP delivery status	Stale: updated days after shipment	Updated: within minutes of tracking event
Goods receipt posting	Manual: 1-3 day delay after delivery	Automated: posted on Delivered event, same day
Invoice generation trigger	Delayed: waiting for goods receipt	Same-day: goods receipt posts automatically
Shipped notification to customer	Manual email (if sent at all)	Automated: triggered on Shipped event
Out for delivery notification	Not sent	Automated: triggered on OFD event
Delivery confirmation to customer	Manual: if CS noticed	Automated: triggered on Delivered event
Exception detection	Discovered when customer complains	Level 2: detected at tracking event receipt
CS team exception alert	Not sent (discovered reactively)	Automated: alert on exception event
Delay alert to account manager	Not sent	Level 3: proactive when EDD > promised date
Weekly on-time delivery reporting	Manual: downloaded and compiled	Level 3: generated automatically
Multi-3PL visibility	Separate portals, no unified view	Unified: all 3PLs in one dashboard
EDI 214 processing	Manual: someone reads EDI files	Automated: parsed and processed
Invoice-to-cash acceleration	1-5 day delay vs delivery	Same-day: goods receipt and invoice trigger aligned

---

Step-by-Step: An Order from Shipment to Delivery Confirmation

Here is the complete automated flow for Sales Order SO-2026-0441 from Meridian Manufacturing, shipped via Kenco’s warehouse to a customer in Austin, TX, using UPS as the carrier.

Setup: Meridian uses NetSuite. Kenco publishes hourly SFTP tracking files. The NetSuite sales order stores the Kenco order reference in custbody_3pl_ref field. Level 2 matches the Kenco order reference to the NetSuite item fulfilment record. Customer email notifications sent via Klaviyo integration.

March 14, 9:00 AM: Kenco SFTP file downloaded. eZintegrations downloads the Kenco tracking file from SFTP. File contains 47 shipment status rows, including:

SO-2026-0441,1Z999AA10123456784,UPS,SHIPPED,2026-03-14 08:45:00,Kenco Austin Warehouse,2026-03-14

March 14, 9:00 AM: Level 2 matching (3 seconds). Kenco order reference SO-2026-0441 matches NetSuite field custbody_3pl_ref on item fulfilment IFIL-2026-0441. NetSuite item fulfilment record found. Customer: Acme Corp. Contact email: sarah@acmecorp.com. Order value: $4,200.

March 14, 9:00 AM: NetSuite item fulfilment updated.

PATCH /services/rest/record/v1/itemFulfillment/{ifil_internal_id}
{
  "shipStatus": "A",
  "actualShipDate": "2026-03-14",
  "trackingNumbers": { "items": [{
    "trackingnumber": "1Z999AA10123456784",
    "trackingnumbertype": { "id": "UPS" }
  }]}
}

NetSuite item fulfilment status: Shipped. Tracking number stored.

March 14, 9:00 AM: Customer Shipped notification sent. Klaviyo API call triggers the “Order Shipped” email to sarah@acmecorp.com:

Subject: Your order SO-2026-0441 has shipped! Track: 1Z999AA10123456784

Hi Sarah,
Your order from Meridian Manufacturing is on its way.
Carrier: UPS | Tracking: 1Z999AA10123456784
Estimated delivery: March 14, 2026
Track: https://www.ups.com/track?trackingNumber=1Z999AA10123456784

March 14, 12:15 PM: UPS API poll detects Out for Delivery. UPS tracking API returns status code 022 (Out for Delivery) for tracking number 1Z999AA10123456784.

March 14, 12:15 PM: NetSuite updated, customer notified. NetSuite item fulfilment shipStatus updated to “Out for Delivery” (custom status field). Klaviyo trigger: “Out for Delivery” email to sarah@acmecorp.com.

March 14, 2:47 PM: UPS API poll detects Delivered. UPS tracking API returns status code 011 (Delivered). Delivery location: “1234 Commerce St, Austin TX 78701”. Delivery time: 14:47.

March 14, 2:47 PM: NetSuite item fulfilment closed.

PATCH /services/rest/record/v1/itemFulfillment/{internal_id}
{ "shipStatus": "C", "actualDeliveryDate": "2026-03-14" }

NetSuite item fulfilment status: Closed (Delivered).

March 14, 2:47 PM: NetSuite invoice triggered. NetSuite item fulfilment closure moves SO-2026-0441 to the billing due list. Invoice INV-2026-0551 generated automatically ($4,200, payment terms Net 30, due April 13, 2026).

March 14, 2:47 PM: Customer delivery confirmation sent. Klaviyo trigger: “Order Delivered” email to sarah@acmecorp.com:

Subject: Your order SO-2026-0441 has been delivered

Hi Sarah,
Your order from Meridian Manufacturing was delivered today at 2:47 PM.
Questions? Reply to this email.
Meridian Manufacturing Customer Service

Total automated actions from shipment to delivery confirmation: 8 ERP updates and 3 customer notifications. Previous manual process: CS team would answer “Where is my order?” around 3 PM after Sarah emailed. Goods receipt posted the following Monday when the warehouse team ran the weekly goods receipt batch. Invoice generated Tuesday.

---

Key Outcomes and Results

Customer service enquiry volume: “Where is my order?” enquiries typically account for 30-40% of customer service contacts for B2B and B2C companies that ship physical goods. Proactive shipment notifications (Shipped, Out for Delivery, Delivered) reduce these contacts by 50-70% by answering the question before the customer asks.

Invoice-to-cash acceleration: the delay between physical delivery and goods receipt posting in the ERP directly delays invoicing. Manual goods receipt posting takes 1-3 days on average. Automated goods receipt on the Delivered event eliminates this delay. For a company billing $5M per month, a 2-day acceleration in invoicing represents significant working capital improvement.

ERP data accuracy: stale delivery status in the ERP (orders showing “In Delivery” for days after they have been delivered) creates inventory inaccuracy, incorrect AP/AR reports, and unreliable on-time delivery metrics. Automated same-day ERP updates eliminate this lag.

Exception response time: manual processes discover delivery exceptions when the customer complains. Automated exception detection notifies the CS team at the moment the carrier reports the exception, typically 24-48 hours earlier than the manual process. Earlier exception awareness enables proactive customer outreach and faster resolution.

On-time delivery visibility: Level 3 generates weekly on-time delivery reports by 3PL, carrier, and lane. This data enables performance conversations with 3PLs based on actual delivery records rather than anecdote.

---

How to Get Started

Step 1: Map Your Current 3PL Tracking Data Flow

Document: which 3PLs do you use? Does each 3PL offer a REST API, SFTP file feed, or EDI 214? How is the 3PL tracking number currently stored in (or linked to) your ERP sales order or delivery document? What field in the ERP holds the tracking number or the 3PL order reference? What is the current delay between physical delivery and ERP goods receipt posting? This mapping exercise (1-2 hours) defines the integration architecture.

Step 2: Confirm ERP Tracking Reference Storage

The most critical prerequisite: the 3PL’s order reference or tracking number must be stored in the ERP in a queryable field. If the tracking number is not currently stored in the ERP, add a custom field to the delivery document or sales order and configure the 3PL outbound order process to populate it when the shipment is created. This prerequisite is what makes reliable Level 2 matching possible.

Step 3: Import the 3PL Shipment Automation Template

Go to the Automation Hub and explore the supply chain automation templates. Import the 3PL Shipment Status Automation template for your 3PL type (DHL REST API, UPS REST API, Kenco/regional SFTP, or EDI 214) and ERP (SAP, NetSuite, or Dynamics 365). The template includes: 3PL API polling or SFTP monitoring, status event parsing, Level 2 ERP record matching, ERP delivery status update, goods receipt posting on Delivered, customer notification email sequence (Shipped, Out for Delivery, Delivered), and exception alert routing.

Step 4: Configure API Credentials, Customer Email Templates, and Test

Connect your 3PL API credentials (DHL API key, UPS OAuth, Kenco SFTP credentials, or EDI 214 AS2 endpoint). Connect your ERP credentials. Configure the customer notification email templates with your brand. Set up the exception alerting channel (email or Slack). Test with 5-10 active shipments: verify that tracking events correctly match ERP records, ERP status updates are accurate, customer emails trigger at the right milestones, and goods receipts post correctly on delivery confirmation.

Total configuration time: 2-4 days for a single 3PL-ERP pair with customer notifications.

---

FAQs

1. How does eZintegrations automate 3PL shipment status updates to the ERP?

eZintegrations connects to your 3PL's tracking data source (DHL REST API, UPS Track API, FedEx Tracking API, regional SFTP file feed, or EDI 214) via polling or webhook. When a tracking event is received, Level 2 matches the tracking reference to the corresponding delivery document in SAP S/4HANA (API_OUTBOUND_DELIVERY_SRV), NetSuite (item fulfilment via SuiteQL), or Dynamics 365 (SalesOrderLines). The ERP delivery status is updated automatically. When the tracking status is 'Delivered,' the goods receipt or goods issue confirmation is posted in the ERP via REST API, triggering downstream invoicing and inventory updates.

2. How long does 3PL shipment automation take to set up?

2-4 days for a single 3PL-ERP pair with customer notifications. Key steps: 3PL API or SFTP credentials (1-4 hours depending on 3PL), ERP tracking reference field verification (1-2 hours), ERP API credentials (1-2 hours), template import and mapping configuration (2-4 hours), customer email template setup (1-2 hours), and test validation with 5-10 active shipments (1-2 days). Add 1-2 days for EDI 214 integration if your 3PL uses EDI rather than REST API.

3. Does eZintegrations work with DHL, UPS, FedEx, and regional 3PLs like Kenco?

Yes, DHL: REST API (/track/shipments), OAuth or API key authentication. UPS: Track API v1 REST, OAuth 2.0. FedEx: FedEx Tracking API, OAuth 2.0 with application credentials. Kenco, Ryder, XPO, and other regional 3PLs: SFTP CSV file feed (hourly or configurable), EDI 214 via AS2, or REST API if available. For 3PLs with proprietary WMS portals: eZintegrations can scrape tracking data via web automation or connect to the WMS API if available. Pre-built templates for DHL, UPS, FedEx, and SFTP-based 3PLs are available in the Automation Hub.

4. How does the ERP record matching work when the tracking number is different from the ERP order number?

Level 2 uses three matching strategies in order of confidence. Strategy 1: the tracking number is stored in the ERP delivery document as a custom field, enabling a direct lookup (WHERE custbody_tracking_number = '{tracking_number}'). Strategy 2: the 3PL order reference includes the ERP sales order number, enabling cross-reference lookup. Strategy 3 (fallback): Level 2 fuzzy matching on customer name, shipping address, approximate order value, and approximate ship date to identify the best candidate ERP record. Match confidence below the configured threshold (default 85%) routes the event to a manual review queue rather than auto-posting. The best practice is Strategy 1: storing the 3PL tracking number in the ERP when the shipment is created.

5. What happens when there is a delivery exception (failed attempt, delay, or damage)?

Level 2 detects exceptions from the 3PL tracking event status codes (DHL: delivery-failure, UPS: 007, FedEx: DL or DE). On exception detection: the ERP delivery document status is updated to 'Exception' (preventing premature goods receipt posting), the customer service team receives an immediate alert with order details and carrier reference, a customer exception notification is triggered (configurable: by default, failed delivery and significant delays trigger customer emails), and the account manager is notified for high-value orders. Level 3 monitors for recurring exception patterns with specific 3PLs or routes to surface performance issues.

---

Sarah Stopped Asking “Where Is My Order?” Before She Sent the Email.

The proactive “Out for Delivery” notification arrived at 12:15 PM. Sarah already knew. She did not need to email your customer service team. The Delivered confirmation arrived at 2:47 PM. The invoice was in NetSuite at 2:47 PM. Finance did not need to chase the goods receipt on Monday.

Three automated notifications. Three ERP updates. One goods receipt posted. One invoice triggered. Zero manual steps.

Explore the 3PL Shipment Automation Templates in the Automation Hub. Or visit the Automation Hub to import the template for your 3PL and ERP combination.

For the related inventory replenishment automation that starts when inbound shipments are received, see the inventory reorder PO automation guide.