Skills / Reconciliation and close

Month-End Accrual Proposals

Finding what a closed period missed is the audit-side procedure. This is the preparer-side mirror of it, run on a period that's still open: instead of searching after the fact, it proposes what to book before the close, so a reviewer approves or rejects each line instead of starting the accrual batch from a blank JE.

What it does

Three sources, in order of reliability. Open purchase orders where goods or services were received but the invoice hasn't shown up yet, the most defensible accrual because it's backed by a receipt rather than an estimate. Recurring vendor spend, utilities, rent, subscriptions, accrued at the trailing average of prior periods, but only when there's enough history and only when the actual invoice for the current period isn't already on file. And one-time items a preparer already knows about, a settlement, a bonus accrual, each of which has to carry its own stated basis; nothing gets proposed on an amount with no reason attached.

Every candidate is classified as proposed, excluded with a reason, or flagged as an exception. Nothing is silently dropped, and nothing is silently proposed either.

Why it cross-checks against the AP register

An open PO report's own "invoiced" figure goes stale the moment an invoice is keyed against that PO after the report was pulled. That's the single most common way a tool like this double-books an accrual: the PO report still says "not invoiced" for something that already is. Supplying the AP register lets the skill catch that before it becomes a proposal. Without one, GRNI candidates are proposed on the PO report's word alone, and the output states that plainly rather than implying a check ran that didn't.

What it won't do

It won't guess an amount for a one-time item with no stated basis. It won't propose a recurring accrual without a minimum amount of trailing history to average, dropping it to an exception instead of a thin guess. It won't ignore a prior-period accrual that never reversed; that's a double-counting risk against anything proposed this period, and it gets its own tab rather than a footnote. And it never posts anything: the deliverable is a proposed batch, built for a Controller to approve line by line, not a booked one.

Inputs and output

InputsOpen PO report, AP invoice register, vendor spend history, prior-period accruals, and any preparer-supplied one-time items
OutputA proposed accrual JE batch, one debit/credit pair per line, each with a basis, a reversal flag, and a reversal date, plus an exceptions list for anything that couldn't be proposed
Who it's forControllers proposing the accrual batch for close, and whoever reviews it before it posts

Related

Glossary: Accrual Accounting · Reversing Journal Entry · Suspense Account

Related skill: the audit-side counterpart this inverts is cutoff-and-unrecorded-liabilities on github.com/adoptai/cpa-skills: that skill proves a search for missed liabilities is complete and reports what it found; this one proposes what to book before anyone's asked for a search.

Go deeper: Financial Close Automation

Adopt's Close Agent runs this end to end inside the systems you already use, so the proposed batch is waiting before the reviewer opens the file. Sign up free, or book a pilot to run it against your own open POs and AP register.