Module

Goods Receipt

What actually arrived, matched against what was ordered and what was billed.

In build — not switched on₹16,000 / month
See pricing

What it produces

  • A receipt document per delivery — date, quantity, who received it — not a running total
  • Three-way match: purchase order against receipt against supplier invoice, line by line
  • The difference named as short delivery, over delivery, price variance or a rate nobody agreed
  • A bill that cannot be approved over an unexplained difference, and says which of the three disagrees

A worked example

Illustrative only — receipts are a quantity today, not a document
the purchase order line already carries received and rejected quantities
what is missing is the receipt event they came from, which is what a match compares against
of the six not built, this is the one already closest to possible

Illustrative figures. On your tenant the same page shows yours.

Why it is hard

The part that is not a report.

A purchase order line here already records what arrived and what was rejected on inspection, so the quantity is known. But a running total is not a receipt, and a three-way match compares three dated documents — order, receipt, bill — to find which of the three disagrees. Without the receipt document there is nothing to match against, and an invoice gets approved on somebody's memory of a delivery. This is the closest of the unbuilt modules to being possible, because the hard part is already recorded.

Opened by WAREHOUSE_MANAGER and the procurement lead — what each of them sees first.

Said before you ask

What we don’t do.

SIAARU decides from your records and nothing else. It carries no copy of the world’s data, states no figure your systems have not, and acts in nobody’s name. Where your data does not support an answer, it says so by name rather than producing a confident one — which is the whole reason a decision taken on it holds up later.

Not built, and the closest of these six to being possible. A purchase order line already records what was received and what was rejected on inspection, so the quantity is known — but a running total is not a receipt, and a three-way match compares three dated documents. The receipt document and the match engine are the work; nothing here matches a bill against a delivery today, and an approved invoice is one person's decision rather than a machine's.

Where this sits

One of 32 modules, on one engine.

Goods Receipt reads the same reconciled data as everything else SIAARU runs — connected read-only to your ERP, scored on the way in, measured in SQL. How that engine works is a page of its own. The other 31 modules, each with the state it is really in and the reason where it is not switched on, are on the module list; what this one costs, and what it costs beside the rest, is on the pricing page.

Get started

Bring one month of data. Leave with your own control tower.

A demo runs on your material master, your purchase orders and your stock — not on ours. Thirty minutes, and you see your own exceptions rather than a scripted one.

Ask a question

Book a demo

Thirty minutes, on your own data. Six fields — the rest only helps us prepare.

Not binding. Tell us the size and we will say which one fits.

The demo connects to it, so this shapes the whole session.

Add context, and the demo runs on your problem rather than a scripted one

We reply within one working day.