Finance Index
How do I accrue for invoices received but not yet processed at month-end?
Reference guide to month end close AP accruals, including invoice workflow, coding, approvals, ERP impact, and AP controls.
Accruing for received-not-processed invoices requires knowing what's in flight - invoices that have arrived but haven't posted to the ERP. With a system that captures invoices at receipt, that's a standing report of pre-posting invoices with amounts and ages; without one, it's an estimate built from inboxes and guesswork. The accrual exists because the liability is real the moment the invoice arrives, regardless of whether accounting has touched it yet, and a blind accrual is the symptom of an invisible in-flight population.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Accrue for invoices received | Accruing for received-not-processed invoices requires knowing what's in flight - invoices that have arrived but haven't posted to the ERP. | Keeps accounting records aligned with the ERP. |
| Get visibility into in-flight unposted | The fix is structural: capture invoices into a system of engagement at receipt, not at posting, so every received invoice has a status and amount before it ever reaches the ERP. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| ERP alignment | The usual causes: invoices entered in the AP tool but not yet posted to the GL (timing), manual journal entries to AP that bypassed the subledger, unapplied credits, posting-period mismatches, and export failures that left invoices stranded between systems. | Keeps vendor records and payment decisions reliable. |
| Accrue for goods received not | Accrue GRNI from receipt records for goods received without a matching invoice, then clear each accrual as the invoice arrives and matches - don't let entries pile up. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Invoices keep trickling in after | Set a documented cutoff date and an invoice-date rule for period assignment, communicate it to the business and vendors, and accrue for known-but-unreceived items rather than holding the close open. | Keeps vendor records and payment decisions reliable. |
How do I get visibility into in-flight unposted invoices for an accurate accrual instead of guessing?
The fix is structural: capture invoices into a system of engagement at receipt, not at posting, so every received invoice has a status and amount before it ever reaches the ERP. Then the accrual is a query - sum everything in pre-posting statuses - rather than a sample of the AP inbox. The reason ERP-only shops guess is that an ERP records accounting events, not work in progress; it literally cannot show invoices it hasn't received yet. Visibility into the in-flight queue is the difference between an accrual you can defend and a plug you hope is close.
Our AP aging doesn't tie to the GL AP balance - what causes this, and how do I reconcile?
The usual causes: invoices entered in the AP tool but not yet posted to the GL (timing), manual journal entries to AP that bypassed the subledger, unapplied credits, posting-period mismatches, and export failures that left invoices stranded between systems. Reconcile by exporting the subledger detail, matching to the GL control account, and investigating the difference line by line. A clean tie-out depends on every AP transaction flowing through one path - manual JEs to the AP account are the most common silent breaker.
How do I accrue for goods received not invoiced (grni) and keep the account from ballooning?
Accrue GRNI from receipt records for goods received without a matching invoice, then clear each accrual as the invoice arrives and matches - don't let entries pile up. A ballooning GRNI account signals invoices not arriving, receipts not closing, or matching breakdowns; review aged GRNI items monthly and chase the missing invoices.
Invoices keep trickling in after close for the prior period - how do I set and enforce an AP cutoff?
Set a documented cutoff date and an invoice-date rule for period assignment, communicate it to the business and vendors, and accrue for known-but-unreceived items rather than holding the close open. Enforcement comes from the accrual catching late arrivals, not from waiting - late invoices post to the period they belong in via the accrual true-up.
How does faster invoice processing shorten my close, and where does AP sit on the critical path?
AP sits early on the close path: until invoices are captured and the accrual is known, downstream steps wait. Faster processing means more invoices are posted (not accrued) by cutoff and the in-flight liability is precisely known, which shrinks accrual work and removes AP as the step everyone waits on.
How should AP handle an invoice dated in a closed period - post date vs invoice date vs GL date?
Keep the invoice date as the document's date, but control the period via the posting/GL date per your ERP's logic - post to the current open period with the original referenced, and accrue materially large prior-period items where policy requires. Don't reopen a closed period for an ordinary late invoice.
What should an AP close checklist include?
All received invoices captured and statused; in-flight accrual calculated from the pre-posting queue; GRNI reviewed; held invoices and open credits swept; subledger reconciled to the GL AP account; exceptions documented; and prior-period accruals reversed/trued. The checklist's job is to ensure no real liability is invisible at close.
How should month-end AP accruals be reversed and trued up the next period without double counting?
Book accruals as auto-reversing entries so they back out at the start of the next period as the actual invoices post, preventing double-counting. Review the reversal against actuals to confirm the accrual was reasonable, and adjust the estimation method if variances are consistently large.
Stampli perspective
Because Stampli holds invoices from arrival rather than from posting, the in-flight population that ERP-only processes can't see is fully visible - real-time status and aging across received, in-review, pending-approval, and approved-but-unposted invoices give finance an accrual built on data instead of estimate. Validating invoices against live ERP structure before export reduces the posting failures and reclasses that distort the AP-to-GL tie-out, and the immutable audit trail makes the close defensible. The result is fewer accrual surprises and a shorter path off the close critical path.