Accrued AP / Goods-Received-Not-Invoiced (GR/NI) Tracker

The problem this kills

It is the last day of the month and you are hunting for expenses that belong in this period but have no invoice yet. The warehouse received the goods. The service was delivered. But the vendor's invoice is still in transit, sitting in someone's inbox, or just late. If you do nothing, those costs land next month and your margins lie to you.

So you build the goods-received-not-invoiced accrual by hand: pull the receipts report, pull the open POs, pull the invoices already booked, and reconcile them line by line in a spreadsheet to figure out what was received but not invoiced — and what it should be worth. It is slow, it is error-prone, and the worst failure mode is silent: accrue something that already has an invoice and you double-count the expense. Miss a receipt and you understate your liabilities. Then you have to remember to reverse the whole thing next month so it nets out correctly.

This is exactly the kind of rules-based, high-stakes reconciliation that a small internal tool does better than a spreadsheet — and you do not need to be a developer to build it.

What you'll build

A simple internal web tool for your close. You import three files — a goods-receipts export, an open-PO export, and a recorded-invoices export. The tool matches them on the PO line, calculates the open quantity (received minus invoiced) as of your period-end date, and values it at the PO unit price. AI proposes one accrual line per PO line that still has uninvoiced value, nets out anything already partially invoiced so you never double-accrue, and flags the messy ones — over-receipts, missing prices, returns — for a human to look at.

The controller reviews the proposed accrual list and amounts on one screen, edits or excludes anything that looks wrong, and clicks Approve. Only then does the tool produce the GL-ready accrual journal entry, a matching auto-reversal dated for the start of next period, and a clean GR/NI schedule you can keep as your support.

What's inside the Implementation Plan

The plan is a single file you paste into an AI coding agent. It opens by interviewing you about your business — which ERP you run, how your receipts reference a PO line, how invoices get matched, your materiality threshold, your period-end and reversal conventions, and your nastiest edge cases — and then tailors the data model, the matching logic, and every later step to your answers. This is a build shaped around your close, not a generic template.

From there it walks the agent through the database schema, the three CSV imports with their duplicate guards, the GR/NI matching and valuation engine, the controller's review-and-approve screen, and the export of the accrual entry, its auto-reversal, and the GR/NI schedule. Every step ends with a ready-to-copy prompt. Because the whole thing runs on CSV in and GL-ready CSV out, you can build and use it this weekend even if you have no direct connection to your ERP.

The governance it includes (this is the point)

This touches the general ledger, so it is built like it matters: login so only your finance team can use it, row-level security so you only ever see your own entity's data, and a complete audit trail of every import, edit, approval, and export — who did what, and when. Nothing posts automatically: the accrual is a draft until the controller approves it, and approval is the hard human-in-the-loop gate before anything becomes a journal entry. Duplicate guards on the PO line — and on each imported file — mean the same receipt can't be accrued twice and the same accrual can't be booked twice.

Who it's for

Controllers and staff accountants who own the monthly and quarterly close and want the GR/NI accrual to be fast, defensible, and the same every period. If you can explain how you decide what to accrue, you can build this.

You've got this — open the plan, paste the first prompt, and let it interview you about your close.