From PO email to approval-ready order.
Each allowlisted Hyperpure PO email becomes a parsed, warehouse-matched order in the FilFlo queue — then runs through the same approval-to-GRN flow as every other channel.
PO email arrives
Hyperpure purchase orders arrive by email — FilFlo's email ingestion receives the message and parses it automatically. No portal scraping, no manual forwarding step.
Sender checked against the allowlist
Before anything is parsed, the sender address is verified against a configured allowlist — mail from an unknown or unexpected sender address is dropped before parsing.
PO parsed automatically
The PO header and lines — quantities, rates and delivery details — are extracted from the email, and the source email is preserved on the order trail so the parsed PO can always be checked against what Hyperpure actually sent.
Warehouse matched by code
Hyperpure's delivery warehouse code on the PO is matched to the fulfilling FilFlo warehouse. If the code isn't mapped yet, a pincode fallback resolves the delivery location.
PO joins the approval queue
The parsed Hyperpure PO lands in the same queue as every other channel — SKU-level quantity cuts with reasons, split-and-approve, the approver on record.
Fulfillment coordinated
Approval generates picklists with batch/expiry/FIFO-aware allocation, followed by scanner-based picking and dispatch scanning where the brand runs its own floor.
Invoice and GRN close the loop
GST invoicing with IRN runs against the right entity and series, and GRN capture compares delivered, received and accepted quantities with variance reasons.
The sender allowlist is the front door.
Email is an open channel, so FilFlo doesn't treat it like one. Before a Hyperpure PO email is parsed, its sender address is verified against a configured allowlist — mail from an unknown or unexpected sender address is dropped before parsing, never queued. Every PO in the queue traces back to a vetted Hyperpure address with its source email preserved for audit.
What crosses the wire.
Parsed automatically from the Hyperpure PO email — quantities, rates and delivery details captured at line level into the FilFlo order queue.
Hyperpure's delivery warehouse code on the PO drives warehouse matching, with a pincode fallback when a code isn't mapped yet.
The original PO email is preserved with the order, so operations and finance can audit the parsed PO against the document Hyperpure sent.
Hyperpure delivery warehouse codes are mapped to FilFlo warehouses before the first PO is processed, stored as per-customer configuration — the mapping is what makes matching deterministic.
What the workflow enforces — and what it expects.
Sender allowlist gates intake
Only email from allowlisted Hyperpure sender addresses is processed. Everything else is dropped before parsing — this is a deliberately restricted email workflow, not an open inbox.
Deterministic warehouse matching
Matching runs on Hyperpure's delivery warehouse code first, with pincode as the fallback — so a PO routes to the fulfilling warehouse by rule, not by guesswork.
Source document preserved
The PO email itself stays attached to the order trail alongside the parsed header and lines, keeping the intake auditable end to end.
Only allowlisted senders are processed
If Hyperpure mails a PO from an address that isn't on the allowlist, it is dropped — not parsed, not queued. New or changed sender addresses need to be added to the allowlist before their POs are picked up.
Warehouse codes must be mapped
Hyperpure delivery warehouse codes need to be mapped to FilFlo warehouses. The pincode fallback covers gaps, but mapping each code before the first PO is processed keeps routing deterministic.
Inbound only
This workflow brings Hyperpure POs into FilFlo. There is no outbound submission back to Hyperpure — approvals, fulfillment, GST invoicing and GRNs run in FilFlo's standard flow after intake.
Frequently asked questions.
How do Hyperpure purchase orders enter FilFlo?
By email, parsed automatically. Hyperpure purchase orders arrive by email; FilFlo's email ingestion receives each message, verifies the sender against a configured allowlist, and extracts the PO header and lines into the order queue. The source email is preserved on the order trail, so the parsed PO can always be checked against the document Hyperpure sent. No manual re-keying, no portal scraping.
What happens if a PO email comes from a sender that isn't allowlisted?
It is dropped before parsing. The allowlist is a deliberate intake control: only vetted Hyperpure sender addresses are processed into the queue, and mail from an unknown or unexpected sender address is dropped before parsing. If Hyperpure starts sending from a new address, that address is added to the allowlist and its POs are processed from then on — until it is added, mail from it is not processed.
How does FilFlo know which warehouse a Hyperpure PO is for?
Matching runs on Hyperpure's delivery warehouse code, which is mapped to the corresponding FilFlo warehouse before the first PO is processed and stored as per-customer configuration. If a code on an incoming PO isn't mapped yet, a pincode fallback resolves the delivery location. Mapping each delivery warehouse code is the setup step that keeps routing deterministic rather than fallback-dependent.
Does FilFlo send anything back to Hyperpure?
No — this is an inbound-only workflow. FilFlo brings Hyperpure POs into the queue; everything downstream — SKU-level approval, picklists, scanner-based dispatch, GST invoicing with IRN, and GRN capture — runs in FilFlo's standard order-to-cash flow rather than through an API back to the platform.
See a Hyperpure PO email become an approval-ready order.
Book a 30-minute demo and watch the full loop: PO email parsed behind the allowlist, warehouse matched by delivery warehouse code, SKU-level approval, and the invoice and GRN that close the order out.