SAP Proof of Delivery

What SAP’s POD function captures today

SAP’s POD function in SD is a real, configurable ledger feature. It is purpose-built for closing the outbound delivery in the ledger so SD can trigger billing, not for capturing evidence in the field on a driver app.

• POD-relevant items. Item categories in SD can be flagged as POD-relevant. When enabled, the outbound delivery cannot be fully billed until the POD step is processed.
• VLPOD transaction. The standard SAP transaction for POD processing. Allows confirmation of quantities actually delivered to the customer, recording differences (overage, shortage, damage), and setting the POD date.
• POD status on the outbound delivery. Status fields and update timestamps on the outbound delivery header and items.
• SAP DMS attachments. Documents can be attached to records (POD certificates, signed delivery notes) via the Document Management System.
• Fiori app for POD. S/4HANA includes Fiori apps for the back-office POD processing role.

Everything above is the ledger and back-office surface for closing the delivery. It is not the surface a driver opens at a customer’s door on the road to capture a signature and a photo, and it is not where the customer-experience evidence (NPS, branded receipt) lives.

What a real POD capture workflow includes

The driver standing at the delivery point has a defined job: prove the load arrived and capture the evidence the business needs. The workflow has to support that without bouncing through ERP forms.

• Photos. The dropped load on the customer’s premises. Damaged carton evidence if the load arrived broken. Asset placement for a piece of equipment.
• E-signatures. From the receiving customer or a named recipient. Captured on the driver’s device, time- and location-stamped.
• Conditional outcomes. Delivered, refused, partial, failed. Each outcome carries a reason code, and each kicks off a different follow-up (invoice immediately vs. trigger a redelivery vs. escalate to customer service).
• Custom forms per task type. Cold-chain delivery: temperature reading at drop. Restricted access: gate access code or doorman name. Hazmat: handling form. Equipment install: asset serial scan.
• Timestamps and GPS. Auto-captured at the moment of completion, irrespective of when the device is online.
• Offline-first. Captures queue on the device if the signal is patchy. Sync happens automatically when it returns.
• References that flow back to the ERP. The image isn’t useful if it sits in the driver’s camera roll. POD has to land on the right ERP record so SD can post goods issue and customer service can audit.

Where S/4HANA users land today without configurable driver POD

Two patterns are common before a driver-app POD layer is added. Both work at small scale and break at volume.

• Camera roll plus manual upload. Driver photographs the dropped load on a personal phone. Driver gets a signature on a paper note pad. At the end of the day someone manually uploads the photos to DMS or attaches them to the outbound delivery, and a back-office user runs VLPOD to set POD status. Cycle-time on billing stretches because POD lands a day or two late.
• Third-party POD app, manual sync. Driver uses a basic POD capture app that lives outside the SAP data model. POD evidence sits in the third-party tool; flow into S/4HANA is a CSV export, a copy-paste, or a scheduled ABAP job. The driver workflow works, the data flow doesn’t.

Either pattern blocks two things: instant goods issue posting and billing on completion, and instant customer service audit when a customer disputes a delivery.

How eLogii captures POD

POD configuration sits at the route, stop or task-type level in eLogii. The same driver app handles different POD flows depending on what the stop needs.

• Photos. Driver captures one or several photos. Images are stored and referenced from the eLogii task.
• E-signature. On-screen signature capture from the receiving customer. Image and signer name held against the task.
• Conditional outcomes. Branching workflows by outcome. A failed stop captures a reason code and can trigger a re-attempt rule or escalation.
• Custom fields. Configurable per task type. Required vs. optional, free-text vs. picklist vs. numeric, with validation.
• Barcode scan. Camera-based scanning for items, pallets, serial numbers, asset tags.
• Time and GPS stamp. Automatic at moment of completion.
• Offline-first. The driver completes the stop and captures everything on the device. Sync happens automatically when signal returns.

How POD writes back to S/4HANA

Once the driver completes the stop, the captured POD data flows from the device to eLogii, and from eLogii to S/4HANA. The exact SAP target is a configuration choice during the integration build, but the typical pattern is straightforward.

1. Driver completes the stop. Photos, signature, conditional outcome, custom form fields captured in the driver app. Offline-first.
2. Sync to eLogii. When signal is available, captures land on the eLogii task in real time. Signature and photo images are stored; references are surfaced on the task record.
3. Write to S/4HANA. The integration writes the POD outcome back to S/4HANA via OData or BAPI (e.g. BAPI_OUTB_DELIVERY_CONFIRM_DEC), setting POD status on the outbound delivery and populating POD-relevant quantities, the POD date, and any Z-fields configured for POD reference, signer name, image URLs, conditional outcome and custom form data.
4. SD and CS see the POD inside SAP. The moment the write-back lands, SD can post goods issue, billing fires, and customer service has the audit trail in S/4HANA.

If a tenant prefers to land POD references on a custom Z-document or DMS attachment instead of directly on the outbound delivery, that is a configuration choice during the integration build.

Frequently asked questions

Does SAP capture proof of delivery natively?

Yes, as a ledger function. SAP’s POD function in SD (Sales and Distribution), processed via transaction VLPOD, records the POD status on the outbound delivery: POD-relevant items, quantities verified at the customer, POD date, and any quantity differences. That closes the loop for billing. It is not a driver-app capture workflow: no in-app e-signature surface on a mobile device, no configurable POD forms per stop or task type, no conditional outcome handling for failed visits with branching workflows, no offline capture for rural routes. SAP’s POD function is the ledger record close; the driver-app capture surface is a separate problem.

What does a real POD capture workflow include?

Photos of the dropped load. E-signatures from the receiving customer or named recipient. Conditional outcomes: delivered, refused, partial, failed and the reason. Configurable form fields per task type: temperature reading for cold-chain, gate access code, asset serial, hazmat handling. Timestamps and GPS coordinates. Offline capture so the driver isn’t blocked by patchy signal. References that flow back into the ERP record.

How does eLogii’s POD capture work?

Configurable per route, per stop or per task type. The driver opens the stop in the eLogii driver app, follows the configured capture flow (photos, signature, custom fields, conditional outcome), and submits. Captures are offline-first; they queue locally and sync when signal returns. References (image IDs, signature image references, form data) sit on the eLogii task, and the integration writes the relevant references and outcomes back to S/4HANA.

Where in S/4HANA does the POD data land?

Typically against the outbound delivery (the standard SD record for a shipment), using POD-relevant fields and custom Z-fields for the POD reference, signer name, signature image URL, photo URLs, conditional outcome and any custom form data. The integration call sets the POD status, which then triggers PGI and billing in SD. Some tenants prefer to land it on a custom Z-document or extension; the exact target is a configuration choice during the integration build. Once written, SD can post goods issue and trigger billing the moment the driver completes the stop.

Can SAP users see the POD inside S/4HANA?

Yes. The POD reference and any captured form data land on the outbound delivery (or whichever record the integration targets) as standard or custom SAP fields. Users with access to that record see the POD without leaving SAP. Photo and signature images can be linked from the record or stored as DMS attachments depending on the integration design.