TL;DR
The two accounts a posted product receipt hits before the vendor invoice arrives. Together they are GRNI, which is why no account carries that name.
They are the two accounts a posted product receipt hits before the vendor invoice arrives — one debited, one credited. Together they are what finance teams call GRNI, goods received not invoiced, which is why searching the product for an account with that name finds nothing.
What exactly are these two accounts?
Microsoft shows the pair in its own posting example. When a product receipt is posted on a purchase, two entries appear:
| Microsoft's description | Account | Side |
|---|---|---|
| "Purchase, Product receipt purchase" | Uninvoiced receipts | debit |
| "Purchase, Product receipt purchase offset" | Accrued purchases | credit |
Read them as a pair and the logic is obvious. The goods are on site, so something of value has arrived — that is the debit. No invoice exists yet, so the obligation to pay is estimated rather than billed — that is the credit.
Neither posting waits for the vendor. The receipt is enough to move both, which is the point: the balance sheet reflects goods you hold and owe for, before anyone has sent you a bill.
The account names are configurable, like any posting profile in the product. What matters is the shape — a receipts account against an accrual account — not the specific captions in your chart.
So why can't I find an account called GRNI?
Because that is accountants' shorthand, not a Dynamics 365 object.
"Goods received, not invoiced" describes a condition: stock has arrived and the vendor invoice has not matched. The product models that condition as the pair above, left open. There is no single balance with that label, no GRNI page, and no GRNI report by that name.
### This is a real source of wasted time Finance teams arrive from other systems where GRNI is a named account or a standard report, search for it, find nothing, and conclude the product does not track it. It tracks it precisely. It just calls the two halves what they are.
If you want the operational list rather than the balance, that lives elsewhere again — in the Documents not invoiced grids, covered separately.
What actually closes them?
The vendor invoice, once it matches.
Matching is the product's own term for the comparison: "Accounts payable invoice matching is the process of matching vendor invoice, purchase order, and product receipt information. Differences among these documents are called matching discrepancies."
And under a three-way policy the comparison includes the receipt quantity: "Three-way matching additionally compares the invoice quantity to the matched product receipt quantity."
When the invoice posts and matches, the accrual reverses and payables takes over. The accrued purchases credit is cleared and replaced by a real vendor balance. Until that happens, the pair stays open and ages.
This matters for who owns the problem. An open line is not a finance error waiting for a finance fix. It is usually a procurement or goods-in condition that finance can see and cannot resolve.
Why does the balance keep growing?
Four shapes, and only two of them are errors. This taxonomy is ours, not Microsoft's — the product publishes no such list — but every open line we have looked at fits one of them:
| Shape | What happened | Is it wrong? |
|---|---|---|
| Not yet invoiced | Goods arrived, the vendor simply has not billed yet | No. This is the account working as designed |
| Partial delivery | Part of the line arrived and was received; the rest is outstanding | No. Correct behaviour, and it will close when the rest lands |
| Duplicate receipt | The same delivery was received twice, so the receipt quantity exceeds what arrived | Yes. Needs cancelling |
| Wrong line | The receipt was posted against a different line or order than the goods belonged to | Yes. Needs correcting |
The first two will clear themselves. The last two will not, and they are what makes the balance look unexplainable.
Age is the practical filter. A line a few days old is almost always shape one. A line several months old, where the vendor has been paid for that delivery on another document, is almost always shape three or four.
What does this mean at month-end?
The balance has to be explainable line by line, not reconciled in total.
A controller signing off on accruals needs to say why each material line is open — and "the vendor has not invoiced yet" is a complete and acceptable answer for most of them. The difficulty is that it is also the answer that looks identical to a duplicate receipt until somebody checks.
That check is the expensive part, because the evidence lives outside the ledger: the delivery note, the signature at the gate, the person who remembers the lorry. The ledger can tell you a line is open. It cannot tell you the goods never came.
About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/
Agentic ERP. We build turnkey AI optimization apps for Dynamics 365 — sidecar applications that run in your own Azure tenancy and solve the calculations a standard ERP is not built to compute. Built on Azure OpenAI, Microsoft Fabric and Copilot Studio. We build these on request, against your data and your environment.
More on the boundary between what Copilot does and what you build: Agentic ERP on Dynamics 365.
If your oldest accrued lines cannot be explained from the ledger alone, the shapes above are where to start. Bring the ten oldest to a 15-minute call.
Sources
- Acquire assets through procurement · fetched and read 2026-10-21 — carries the posting table naming both accounts
- Set up Accounts payable invoice matching validation · fetched and read 2026-10-21
- Automated vendor invoicing processes overview · fetched and read 2026-10-21
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | The posting pair, with Microsoft's own descriptions and both account names | T1 — read off Microsoft's posting table, names character-exact | acquire-assets-procurement | PASS |
| 2 | 1 | The debit/credit reading — goods arrived, obligation estimated | T2 — ours, plain accounting logic | — | PASS |
| 3 | 1 | Account names are configurable | T2 — ours, true of posting profiles generally. Stated so the article does not imply your chart must use these captions | — | PASS |
| 4 | 2 | There is no account, page or report named GRNI | T2 — ours, and bounded. This is an absence claim. It is scoped to the product calling the two halves what they are, and rests on the posting table using different names. It is not a claim that no Microsoft page anywhere uses the acronym | — | PASS — see note |
| 5 | 3 | "Accounts payable invoice matching is the process of matching vendor invoice, purchase order, and product receipt information. Differences among these documents are called matching discrepancies" | T1 — verbatim | matching-validation | PASS |
| 6 | 3 | "Three-way matching additionally compares the invoice quantity to the matched product receipt quantity" | T1 — verbatim | Same page | PASS |
| 7 | 3 | The accrual reverses and payables takes over when the invoice matches | T2 — ours, the standard consequence, not quoted as Microsoft's wording | — | PASS |
| 8 | 4 | The four shapes — not yet invoiced, partial, duplicate, wrong line | T2 — ours, and the article says so in its own sentence: "This taxonomy is ours, not Microsoft's — the product publishes no such list" | — | PASS |
| 9 | 4 | Age is the useful filter | T2 — ours, practitioner judgement, no figure attached | — | PASS |
| 10 | 5 | The evidence that settles an old line sits outside the ledger | T2 — ours, the cluster's argument | — | PASS |
Tier summary: 3 × T1 (all verbatim), 7 × T2 — 0 × T4.
### ⚠️ This article is T2-heavy, and that is deliberate — but it changes what it can claim Three verbatim quotations carry the facts. The rest is practitioner reading, and every piece of it is labelled: the four shapes say "ours, not Microsoft's" in the body, the configurability of account names is stated rather than assumed, and the month-end argument is offered as a view. Claim 4 is the one to watch. "There is no GRNI account" is an absence, and absences need a wider search than presences. It is bounded in the body — the article says the product "calls the two halves what they are" and points the reader at where the operational list does live, rather than asserting the acronym appears nowhere in Microsoft's documentation.
🔴 No pricing. Microsoft's posting example uses an illustrative amount; the figure is not reproduced, only the debit/credit structure.
No figures of ours. No volume, no ageing threshold, no percentage, no customer. "Several months" is deliberately qualitative — we have measured no distribution of line ages and will not imply one.
Share this article
Procure-to-Pay Agent Operations
Topic Cluster
