How Hubler Captures GRNs — Mobile, WhatsApp, Email, PDF, and Every Channel In Between

Here is the reality of goods receiving in an Indian enterprise.

At Store 1 in Mumbai, a delivery arrives at 9am. The store manager photographs the delivery challan on his phone and sends it to the procurement WhatsApp group.

At Warehouse 14 in Delhi, a supplier emails a PDF packing list with the delivery. The receiving team prints it, signs it, and scans it back.

At Dark Store 47 in Bengaluru, the replenishment van arrives. The picker opens the Hubler app, scans the PO barcode, and confirms items line by line on the mobile screen.

At the manufacturing plant in Pune, the ERP terminal logs the goods receipt directly in SAP when materials enter the stores.

At the corporate office, the procurement team receives an ASN — an Advance Shipping Notice — from a key supplier the evening before a large delivery.

Five different locations. Five different channels. Five different ways the same fundamental event — goods received — is documented. And all five need to reach the same three-way matching engine before any invoice is approved for payment.

This is the multi-channel GRN problem. It is not exotic. It is how receiving actually works at enterprise scale. And it is the reason most AP automation programmes under-deliver — they solve the invoice side but assume the GRN arrives from a single, clean source. Hubler solves it from every direction.

Why GRNs Arrive Through So Many Channels

Reason 1 — Receiving happens at the edge, not at the centre. Goods are received at stores, warehouses, dark stores, manufacturing plants, construction sites, and field locations. Most of these locations do not have dedicated receiving clerks with ERP terminal access. The person receiving the goods is a store manager, a warehouse operative, a site engineer, or a field agent — whoever is present when the delivery arrives.

Reason 2 — Suppliers have different documentation capabilities. A large enterprise supplier sends EDI 856 ASNs. A mid-size supplier sends a PDF packing list by email. A local vendor shows up with a handwritten delivery challan. A logistics partner provides a signed proof of delivery document. The receiving enterprise has no control over how suppliers document their deliveries.

Reason 3 — The existing communication infrastructure is WhatsApp and email. In Indian enterprise operations, WhatsApp and email are the dominant communication channels at the field level. When something needs to be communicated quickly — including proof of delivery — field teams use what they already use.

Reason 4 — Legacy processes are not being replaced, they are being complemented. Many enterprises have WMS systems in some warehouses, ERP terminals in others, and no formal receiving system at retail locations. The solution cannot require replacing all of these — it must work alongside what already exists.

Channel 1 — The Mobile App: GRN at the Point of Delivery

The most direct and most controlled channel. The receiving team creates the GRN at the moment of delivery using the Hubler mobile app on iOS or Android.

The delivery arrives. The receiving team member opens the Hubler app and pulls up the relevant purchase order — either by scanning the barcode on the supplier's delivery documentation or by searching by PO number or supplier name. The PO is displayed with all expected line items. The receiving team confirms each line: quantity received, condition, batch code and expiry date, temperature at delivery for cold chain goods, and any custom fields configured for the category. Discrepancies are documented with a note and a photograph, permanently attached to the GRN record.

What the mobile app captures that other channels cannot:

• Photo evidence of delivery condition and any damage
• Temperature at delivery for cold chain compliance
• GPS location confirming receipt at the correct delivery point
• Identity of the receiving team member with timestamp
• Line-by-line confirmation rather than a document-level acknowledgement

Best suited for: Retail stores, dark stores, franchise locations, field delivery points, any location where goods are received by non-specialist staff without ERP access.

Channel 2 — WhatsApp: The Photograph of the Delivery Challan

In Indian enterprise supply chains, the first documentation of a delivery is often a WhatsApp photograph. The store manager photographs the delivery challan — the GST-mandated document that travels with goods in transit under Rule 55 of the CGST Rules — and sends it to the procurement or operations group. Before Hubler, this photograph went into a WhatsApp group and contributed nothing to the AP workflow.

How Hubler processes WhatsApp delivery photos:

1. Image quality assessment — The image is assessed for legibility. If too dark, blurred, or partially obscured, the system flags it for a retake before processing continues.
2. OCR extraction — Optical Character Recognition extracts supplier name and GSTIN, consignee details, challan number and date, HSN codes, item descriptions, quantities, and any PO reference number included on the challan.
3. PO matching — The extracted PO reference is matched to an open PO. If no PO reference is on the challan, matching is attempted using supplier name, item descriptions, and expected delivery windows.
4. Draft GRN creation — A draft GRN is created from the extracted data, pre-populated with the supplier, items, and quantities from the delivery challan.
5. Receiving team confirmation — The draft GRN is sent to the receiving team as a mobile notification. One tap to confirm a clean delivery; a few taps to correct discrepancies or add damage notes.
6. GRN confirmed and connected to AP — Confirmed GRN is immediately available for three-way matching.

India-specific advantage: the delivery challan is a legally mandated document under GST. Processing it via OCR not only creates the GRN — it also captures the GST-relevant data (supplier GSTIN, HSN codes, challan number) needed to support Input Tax Credit claims and maintain a complete GST documentation chain.

Channel 3 — Email: PDFs, Scanned Documents, and Supplier Invoices

Suppliers frequently send delivery documentation by email — PDF packing lists, scanned delivery notes, or in some cases the invoice and delivery note combined. In many enterprises, these emails arrive at a generic procurement or AP inbox and require manual processing.

How Hubler processes email delivery documentation:

1. Attachment identification — The email is scanned for attachments. PDF, image, and structured data files are identified and queued for processing.
2. Document classification — Each document is classified — delivery note, packing list, invoice, or other. Documents classified as delivery-related proceed to GRN extraction. Documents classified as invoices are routed to the invoice matching workflow.
3. Structured data extraction — Hubler extracts supplier reference, PO number, delivery date, item descriptions, quantities dispatched, and batch numbers or expiry dates where present on the document.
4. Extraction confidence scoring — Each extracted field is assigned a confidence score. High-confidence extractions proceed automatically. Fields below the confidence threshold are flagged for human review before the draft GRN is created — preventing incorrect data from entering the matching workflow.
5. PO matching and draft GRN — Extracted data matched to open POs. Draft GRN created and routed to the appropriate receiving location for confirmation.

For email invoices that also serve as delivery documentation — combined tax invoice cum delivery challan — Hubler identifies these dual-purpose documents and routes delivery data to GRN creation while simultaneously routing invoice data to the three-way matching engine.

Channel 4 — PDF Upload: The Document on the Desk

Sometimes the documentation is not in an email. It is a physical paper that has been scanned, a PDF on a shared drive, a document downloaded from a supplier portal, or a file attached to a procurement platform message. The Hubler web interface and mobile app both support direct document upload. The same document intelligence pipeline applies: document classification, OCR extraction, confidence scoring, PO matching, draft GRN creation and routing for confirmation.

Hubler's document intelligence is trained on the common formats used in Indian enterprise procurement:

The confidence threshold approach ensures that what gets into the system is accurate — low-confidence extractions are flagged for human review rather than passed into the GRN workflow automatically.

Channel 5 — ASN (Advance Shipping Notice): The Proactive Channel

For suppliers with EDI or portal capability, the Advance Shipping Notice (ASN) is received before the goods arrive — sometimes hours, sometimes days in advance. An ASN is a structured electronic document from the supplier confirming that specific goods have been dispatched: the purchase order being fulfilled, items shipped with lot numbers and expiry dates, expected delivery date and time window, transporter and vehicle reference, and number of packages with weights and dimensions.

When an ASN is received (via EDI, API, or supplier portal), Hubler creates a pending GRN — a pre-populated receipt record that is ready and waiting when the delivery arrives. When the goods arrive, the receiving team's job is a confirmation, not a data entry exercise. They check against the pre-populated pending GRN, confirm quantities actually received, note any condition issues, and submit. Discrepancies between the ASN and actual delivery are documented automatically.

ASN processing reduces receiving time by 60–70% at locations with high-volume structured delivery relationships. Supported ASN formats include EDI 856 (ANSI X12), EDIFACT DESADV, supplier portal structured uploads, API-delivered ASN data, and Hubler Vendor Portal ASN submission.

Channel 6 — ERP Goods Receipt: The Existing System

Many enterprises already have ERP systems with goods receipt modules — SAP MIGO, Oracle PO Receipt, Microsoft Dynamics receiving, NetSuite item receipts. For locations with ERP terminal access, these existing workflows are not replaced. Hubler connects to the ERP's goods receipt module via bidirectional API integration. When a goods receipt is confirmed in the ERP, the event triggers Hubler to retrieve the confirmed receipt data and create a corresponding GRN record — immediately connected to the three-way matching engine. No duplicate entry, no separate process.

Channel 7 — WMS Integration: The Warehouse System

For enterprises with Warehouse Management Systems at large distribution centres or third-party logistics operations, the WMS is the system of record for all receiving activity. The WMS confirms receipt at the warehouse level — by pallet, by case, by item. Hubler retrieves this confirmation via API or webhook and creates the corresponding GRN for the AP matching workflow. No additional action required from the warehouse team. No duplicate entry. The WMS continues to be the warehouse's system of record for inventory. Hubler uses the WMS confirmation as the financial control document for AP purposes.

How All Channels Feed the Same Matching Engine

The critical point — and the feature that makes multi-channel GRN capture genuinely valuable rather than just comprehensive — is that every channel feeds the same three-way matching engine.

A GRN created from a WhatsApp delivery challan photograph in Mumbai is treated identically to a GRN created in SAP at the Pune manufacturing plant. Both are matched against the same purchase order. Both are matched against the same supplier invoice. Both produce the same audit trail. The AP team does not need to know which channel a GRN came from — they see the GRN status in the matching dashboard and the matching engine works the same way regardless of origin.

The Audit Trail — Every Channel, Every Document

Regardless of which channel created the GRN, the audit trail records the complete event history — from the original document or action that triggered it, through every processing step, to the final confirmation and the invoice match that follows. Every GRN has a complete chain of custody: the original document or action, each processing step with timestamps, the confirming team member's identity, and the subsequent three-way match result. Corrections made during human review of low-confidence OCR extractions are logged alongside the original extraction — the complete document processing history is preserved.

What This Means for Indian Enterprise Procurement

The multi-channel GRN capability matters particularly in the Indian context for three reasons.

The delivery challan is ubiquitous. Every significant goods delivery in India is accompanied by a delivery challan — a legally mandated document under GST. By reading delivery challans via OCR from photographs or scanned documents, Hubler converts the existing documentation infrastructure into GRN data without requiring new processes from suppliers or receiving teams.

WhatsApp is the real communication layer. In Indian enterprise operations, WhatsApp is not a consumer messaging app — it is an operational communication channel. Real decisions, real confirmations, and real documentation flow through WhatsApp every day. Integrating with this channel rather than fighting it converts existing behaviour into structured data.

Supplier capability is heterogeneous. Large Indian retailers and manufacturers work with suppliers ranging from global MNCs with sophisticated EDI capability to local vendors who operate informally. A single-channel GRN system can handle the MNCs. A multi-channel system handles the entire supplier base.

GRN Coverage That Matches Your Receiving Operation

Single-channel GRN systems achieve high automation rates at the locations and with the suppliers they were designed for — and create exceptions everywhere else, leaving the AP team with a significant manual burden. Hubler's multi-channel approach achieves high automation rates across the full supplier base and the full location network, because it meets receiving staff and suppliers where they already are.