--- title: "What are Uninvoiced receipts and Accrued purchases in Dynamics 365?" canonical_url: "https://cognilium.ai/blogs/uninvoiced-receipts-accrued-purchases-dynamics-365" slug: "uninvoiced-receipts-accrued-purchases-dynamics-365" section: "blogs" date_published: "2026-10-21" date_modified: "2026-10-21" word_count: 1027 reading_time_minutes: 5 author: "Mudassir Marwat" author_identifier: "0009-0008-1927-2598" person_same_as: - "https://www.linkedin.com/in/mudassir-marwat/" - "https://orcid.org/0009-0008-1927-2598" - "https://github.com/mudassirmarwat" - "https://medium.com/@mudassir-marwat" - "https://www.youtube.com/@mudassir-marwat" - "https://dev.to/mudassirmarwat" - "https://hashnode.com/@mudassirmarwat" - "https://huggingface.co/mudassirmarwat" - "https://bsky.app/profile/mudassir-marwat.bsky.social" - "https://substack.com/@mudassirmarwat" - "https://topmate.io/mudassirmarwat" - "https://fueler.io/mudassirmarwat" - "https://www.instagram.com/mudassirmarwat/" - "https://www.facebook.com/mudassir.marwat" - "https://www.reddit.com/user/mudassirmarwat/" - "https://www.f6s.com/member/mudassir-marwat" - "https://cognilium.ai/founder" entities: [] related: [] --- # What are Uninvoiced receipts and Accrued purchases in Dynamics 365? 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. ## Key takeaways - A posted product receipt debits an uninvoiced receipts account and credits an accrued purchases account. That pair is what finance teams call GRNI. - There is no account or report named GRNI in the product, which is why searching for one finds nothing. The condition is modelled as the open pair. - The vendor invoice closes it, once it matches — and under a three-way policy the comparison includes the receipt quantity. - Most open lines are correct. Not-yet-invoiced and partial deliveries clear themselves; duplicates and wrong-line receipts do not. - Age is the useful filter, because the shapes look identical on day one and quite different after several months. - The evidence that settles an old line usually sits outside the ledger, with the person who took the delivery. **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: **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](/blogs/documents-not-invoiced-dynamics-365). ## 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: **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](/erp-ai). 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](https://learn.microsoft.com/en-us/dynamics365/finance/fixed-assets/acquire-assets-procurement) · **fetched and read 2026-10-21** — carries the posting table naming both accounts - [Set up Accounts payable invoice matching validation](https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/tasks/set-up-accounts-payable-invoice-matching-validation) · **fetched and read 2026-10-21** - [Automated vendor invoicing processes overview](https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/auto-vendr-invc-process) · **fetched and read 2026-10-21** ## Fact-check **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. ## Frequently asked questions ### 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: ### So why can't I find an account called GRNI? Because that is accountants' shorthand, not a Dynamics 365 object. ### What actually closes them? 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." ### 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: ### What does this mean at month-end? The balance has to be explainable line by line, not reconciled in total. --- Canonical HTML: https://cognilium.ai/blogs/uninvoiced-receipts-accrued-purchases-dynamics-365