Multi-Vendor Receiving: From the Dock to Accounts Payable

A mid-size grocery store on a busy day receives refrigerated grocery from the warehouse, a produce truck, a dairy drop, dry pallets from the DC, and eight or ten DSD vendors who pull up on their own schedule and deliver straight to the shelf. The receiving dock is where all of it converges. Scheduling it, capturing what actually came in, catching what did not match the purchase order, and posting the result to accounts payable and the item file are four separate problems, and they compound each other when any one of them runs on paper.

This article covers how that receiving flow works end to end: dock appointments, the two paths goods take into a store or DC, how discrepancies get resolved, and the integration that keeps AP and inventory from drifting away from what actually arrived.

Dock scheduling: the problem before the goods arrive

Without a published schedule, every vendor arrives when their driver's route happens to bring them. Two large warehouse deliveries and three DSD trucks can stack at the dock at the same moment, with no dock free, refrigerated product sitting on a trailer warming up, and the receiving team unable to start any of them properly. The cost is not a missed delivery: it is fifteen minutes of detention per truck, perishables outside temperature control, and a receiving team in triage mode for the rest of the morning.

Appointment windows solve the stacking problem. Each vendor gets a time slot tied to the available docks. The slot accounts for how long the unload takes, how much cube arrives, and whether the load is perishable (which biases the slot toward early in the day). Vendors who want to flex their arrival get an acceptable window in addition to a preferred one; the scheduler can place them anywhere in the acceptable window without a phone call. The Multi-Vendor Receiving Dock Scheduler handles this planning in the browser, flags conflicts before truck day, and exports the day's timeline.

The practical limit of a browser tool is that vendors have to be called if the schedule changes. The next step is a vendor self-service portal where vendors see open slots, pick their own, and the assignment flows directly into the purchase-order system so the receiver opens the morning to a finalized timeline tied to the POs being checked in. That is the kind of receiving coordination system I build for grocery and distribution operations.

Two receiving paths: DC freight and DSD

Most grocery inventory takes one path: the retailer's DC ships it, and the receiving team checks it against a purchase order the retailer's own system generated. The receiver verifies quantity, notes any shorts or overages and any visible damage, and the receipt is posted against the PO. An EDI 856 advance ship notice from the DC typically arrives before the truck, so the expected quantities are already in the system by the time the driver backs in.

DSD takes a different path. The vendor owns the product all the way to the shelf, stocks it themselves, and bills for what they say was delivered. The receipt is not the retailer's PO checked off: it is the vendor's delivery record, which arrives at the dock either as DEX (handed device to device at the door) or as an EDI 894 transaction sent over the wire. The DSD deliveries article covers what is inside those documents. The tools for reading them are the DEX/UCS File Explorer and the EDI 894/895 Explorer.

Both paths end at the same place: a receipt that has to agree with what accounts payable will eventually see on an invoice. The difference is who produced the delivery record and how reliably it matches what the retailer's systems already know.

The three-way match and what happens when it breaks

Accounts payable posts a payment when the purchase order, the receiving receipt, and the vendor's invoice agree on item, quantity, and cost. That is the three-way match. When all three agree, payment is automatic. When they do not, the invoice goes on hold until the discrepancy is resolved: a short is credited, an overage is returned or negotiated, a cost mismatch is either approved as a cost change or sent back to the vendor.

The match works cleanly when all three documents are in the system and structured. For a warehouse receipt, the PO was created in the retailer's system, the 856 ASN from the 856 advance ship notice arrived before the truck, and the 810 invoice will follow. For a DSD vendor, the purchase order may be informal or absent, the receipt is the 894 document from the dock or the wire, and the invoice may be the same 894 or a separate 810. In either case, the AP team needs all three documents as structured data before they can match them. Paper delivery tickets that get rekeyed into the AP system are where the match breaks down.

The failure mode is consistent: receipts captured on paper or in a silo that does not connect to AP means the people posting the invoice are working from what the vendor says was delivered, not from what was actually received and recorded. Shrinkage, theft, damage, and vendor shortfalls all look the same from AP's desk if the receipt is not in the system.

Updating the item file and on-hand without rekeying

Every receipt, warehouse or DSD, needs to update two things downstream: accounts payable (covered above) and the item file or on-hand inventory count. A warehouse receipt posts the received quantity against the on-hand balance and records the cost that arrived. A DSD receipt does the same, but the cost that arrives is the vendor's cost embedded in the 894, which may differ from the item's current cost on file. If the cost changed, the item's cost record needs to update, or margins will be wrong until someone notices.

When receiving runs on paper, neither update is automatic. Someone reads the delivery ticket, types the quantity into the back-office system, and eventually posts it. Transposition errors, forgotten entries, and delays between receipt and posting are all normal. By the time the on-hand reflects reality, the item may have already scanned through the register and appeared as a phantom stockout.

The integration that removes this is straightforward in principle: DEX or EDI 894 arrives at the dock, gets parsed, each line is matched against the item file by UPC, the received quantity is posted to on-hand, and the cost is compared against the item's current cost. Mismatches route to a review queue; clean receipts post automatically. I build exactly this kind of receiving pipeline, connecting the DSD data stream to the ERP or merchandising system that needs it, including the older IBM i and Linux-hosted host systems where much of this still runs. See integration services and grocery and retail services for more on how that work is shaped.