Goods received note to Excel

Why the GRN is the weak link

Of the three records a stock reconciliation needs, two are produced by systems. The invoice comes from the supplier's accounting software. The stock ledger comes from yours. The goods received note is produced by a person on a concrete floor, often in a hurry, sometimes in the rain.

So it is the record most likely to be incomplete, illegible or absent — and it is the one that cannot be reconstructed. An invoice can be re-requested from the supplier. A ledger entry can be re-derived. Nobody can tell you three months later how many boxes came off a lorry if it was not written down at the time.

That asymmetry is worth understanding before spending money on stock control software. Sophisticated valuation logic sitting on top of delivery notes that were signed without counting is precision without accuracy. The cheapest improvement available to most stock-heavy businesses is not a system — it is a count at the door, written down.

flowparse.io

Which documents count

Several documents do a similar job with different names, and any of them is useful. What matters is whether a quantity per product was recorded at the point of arrival, not what the piece of paper is called.

The third row is the common case and the one to be honest about. A supplier delivery note signed without checking records the supplier's claim, not your observation — so when it disagrees with the invoice it will not, because they came from the same place.

What comes out of each document

Product description, product code where present, quantity received, unit of measure, and where the document shows both ordered and received quantities, both. At document level: supplier, date, reference or order number, and the source file and page.

The unit of measure is worth the same emphasis it gets on the invoice side. A delivery note saying «12» is not comparable to an invoice saying «12» unless both are in the same unit, and warehouse paperwork frequently counts in whatever the goods physically arrived as — pallets, cartons, cases — rather than in the unit anybody buys or sells in.

Where a document records both ordered and received, keep both. The difference between them is the supplier's own admission of a shortfall, which is considerably easier to claim against than a discrepancy you calculated yourself.

Handwritten counts

Warehouse annotation is usually handwritten: a printed delivery note with quantities crossed out and corrected in pen, a tick against each line, a note saying «2 damaged». That is the most valuable information on the page and the hardest to read.

Legible figures are extracted. Illegible ones are flagged rather than guessed, and the distinction is deliberate: a received quantity feeds directly into a stock difference, so an invented number does more damage than a blank. A field marked uncertain gets thirty seconds of human attention; a field silently misread gets none and stays wrong.

A practical note for anyone designing their own paperwork: a printed line with a box to write the counted quantity in reads far better than free annotation in a margin, and it costs nothing to add. The businesses that get most out of this are the ones whose delivery notes were designed to be counted on.

flowparse.io

Photographs from the loading bay

A large share of these documents reach the office as phone photographs, which is a reasonable process and not a failure. The paper stayed with the goods, someone photographed it, the image went into a chat or an email.

Those images work. OCR handles the reading, then the structuring and confidence flagging are identical to a clean PDF. What changes is the proportion of fields that need review, and that is driven almost entirely by capture quality rather than by anything downstream.

Three things improve it more than anything else, and all three are free: photograph the page flat rather than at an angle, get the whole page in frame including the header, and avoid shadow across the middle. Thirty seconds of care at the bay reliably saves several minutes of correction at a desk — although it never feels that way while holding a phone in a doorway.

Partial deliveries, splits and back orders

One order frequently becomes several deliveries, and the resulting paperwork is where reconciliations most often go wrong in an avoidable way. Two delivery notes against one invoice looks like a duplicate. One invoice against two notes looks like a shortfall on each.

Because each document is extracted with its own date, reference and quantities, the sequence is visible: the same order number appearing twice with different quantities on different dates is a split, not a discrepancy. Recognising that is the step that prevents the most unnecessary supplier calls.

Back orders are the version that spans a period end, and they need watching. Goods promised in one month and delivered in the next are not stock until they arrive, regardless of what the order said — which is the same cut-off question the reconciliation guide covers in more detail.

How it works

flowparse.io

Matching received to invoiced

With both sides extracted, the comparison is mechanical: invoiced quantity, received quantity, difference — grouped by product code and by supplier reference. That is the reconciliation, and it takes minutes once the data exists.

What the difference means is not mechanical, and that boundary is worth keeping clear. A shortfall might be a genuine short delivery worth claiming, a split shipment where the balance arrives next week, or a miscount at the door. Each has a different resolution and only a person can tell them apart.

Match on product code rather than description wherever a code exists. Warehouse paperwork describes items even more loosely than invoices do — the same product is «blue widget 500» on one note and «WIDGET BLU» on the next — and matching on text splits one product into several, each of which then appears short.

The invoice side of this is covered on the supplier invoice quantities page, and the whole comparison on stock purchase reconciliation.

Proof of delivery, and what it does not prove

Carrier proof-of-delivery documents are often treated as settling the question, and they usually settle a different one. A POD proves that something was delivered to an address and signed for. It rarely proves what was inside.

That distinction becomes expensive in a dispute. A signed POD is strong evidence that a consignment arrived, and almost no evidence about the quantity of each product in it — which is precisely what a short-delivery claim turns on. The document that carries weight there is your own count, annotated at the time.

Extract PODs anyway; they are useful for establishing dates and for cut-off at period end. Just do not let their presence substitute for a count, which is the mistake that makes claims unwinnable months later.

A month at a time

One document at a time is a spot check. Batch processing takes up to 100 files into a single export with every row recording its source, so a month of receiving becomes one table.

That is the shape the analysis needs. Which suppliers deliver short, and how often. Which products are consistently over or under. Whether the discrepancies cluster on particular days — which, more often than anyone expects, turns out to correlate with who was on the door.

None of those questions can be answered one document at a time, which is why per-delivery checking alone never produces the pattern people assume it will.

What the data tells you about your receiving process

An unexpected benefit of digitising delivery paperwork is that it measures the paperwork. Once a month of notes is in a table, the gaps are visible: deliveries with no note at all, notes with no quantities, notes where the printed figure was never checked.

That is usually more valuable than the reconciliation itself in the first month, because it identifies where the process breaks rather than just what it cost. A supplier whose deliveries are never counted is a supplier who could be shorting you indefinitely without any possibility of detection.

It also gives a receiving team something fair to work with. «Count everything more carefully» is not actionable. «These four suppliers account for most of the unchecked deliveries, and two of them arrive at eight in the morning» is a conversation about staffing, and one that can actually be resolved.

flowparse.io

When to capture it, and why the answer is «now»

Delivery paperwork has a short useful life. Not because the paper degrades, but because the memory around it does — and much of what makes a delivery note useful is context that lives in somebody's head for about a week.

The gradient is steep between the first two rows and the last two. Same-day capture costs almost nothing and preserves everything; year-end capture preserves the document and none of the context that made it useful.

Which argues for capturing at the bay rather than in the office. A photograph taken as the delivery is checked, sent immediately, is both the cheapest workflow and the one that keeps the evidence alive — and it removes the folder as a point of failure entirely.

Five mistakes

Signing without counting. The signature then records that a lorry arrived, which is not the fact anybody later needs. Nothing downstream can supply the missing number.

Treating the supplier delivery note as your record. It states what they sent. When it agrees with the invoice, that agreement proves nothing — both came from the same source.

Filing rather than extracting. A folder in a warehouse office cannot be compared to anything. The document existing is not the same as the record existing.

Matching on description. Warehouse wording is looser than invoice wording, so one product becomes three and each looks short.

Assuming a POD settles quantity. It settles arrival. A short-delivery claim turns on your count, and that has to have been made at the time.

Who this is for

A full monthly cycle for a distributor is worked through on the wholesale stock control page.

What this is not

It does not create a count that was never made. If a delivery note was signed with no quantities on it, the received record does not exist for that delivery and no extraction can invent one. That is a finding worth acting on rather than a gap to paper over.

It does not decide what a difference means, and it does not convert units between the warehouse's counting convention and yours — both are decisions where a silent wrong answer is applied consistently, which makes them exactly the kind of thing a person should record once.

And nothing is kept: the original file is deleted immediately after extraction, processing runs on EU-hosted infrastructure over TLS, and documents are never used to train AI models — the security page has the detail.

Frequently asked questions

Keep reading