What are posting periods and period locks in an ERP, and how should AP work with them?

Restrict reopen rights to the controller or a named delegate - never AP processors - and require a documented reason, a defined re-close date, and a post-reopen review of everything that posted in the window. Auditors test exactly this: who can reopen, how often it happens, and whether post-close postings get reviewed. Frequent reopening is a close-quality symptom worth tracking.

Good integration behavior is pre-validation: check the target period before attempting to post, and if it's closed, surface a clear, actionable error to AP - with a path to repost to the correct open period - rather than failing silently or retrying blindly. The worst pattern is an integration that queues failures invisibly while AP believes invoices posted.

It flips a control flag that rejects (or restricts) postings dated in that period, by module or ledger depending on the ERP. Closing doesn't change data - it freezes the population so reconciliations and reports stay stable.

Most ERPs offer gradations: a soft close restricts most users while allowing controlled postings (accounting only), a hard close/lock blocks everything without explicit reopening. NetSuite's period close checklist, Intacct's module-level close, BC's allowed-posting-date ranges, and SAP's OB52 period control are all flavors of the same idea.

Only when the period is reopened deliberately for a material correction, by someone authorized, with documentation - and rarely. The default answer for a late invoice is accrue or post forward; backposting is the exception path, not a convenience.

If you're still in close and it's material: reopen-and-post or accrue, per policy. After reporting: post to the current period (immaterial) or treat as a prior-period adjustment with controller involvement (material). The decision rule should be written down with thresholds so AP doesn't improvise.

Prevent: hard-lock periods after reporting and strip reopen rights to one role. Detect: run a posted-after-close report comparing period totals to the reported snapshot each month. If your ERP allows "closed but postable by admins," monitor the admins.

The posting/GL date controls the accounting period; the document (invoice) date is the vendor's date and drives payment terms. ERPs vary in naming, but the rule is universal: AP must consciously manage the posting date at month boundaries rather than letting it default.

Close the AP layer first: stop period-dated postings from the AP system, confirm everything in-flight has either posted or been accrued, reconcile the two systems, then lock the ERP period. The integration should make "what hasn't synced yet" a visible queue, because stragglers that post after the ERP locks become next month's reconciling items.

Yes - most multi-entity ERPs control periods per entity/subsidiary. Shared-services teams typically lock transactional entities on a rolling schedule (day 1-2), then entities receiving allocations, then elimination/holding entities, tracking lock status centrally so no entity's stragglers reopen another's close.

The mechanics are identical; the dates aren't month-ends, so vendor invoices (dated on calendar months) routinely straddle period boundaries. AP needs the fiscal calendar visible in its tools and a clear rule for assigning calendar-month invoices to fiscal periods - retail and food-service teams live this every period.

Restricted reopen rights with an approval trail, system logs of period status changes, a review of entries posted after the period first closed, and consistency between the close calendar and what actually happened. They're testing whether reported numbers could change without anyone noticing.

Adjustment periods (SAP's special periods, NetSuite's period 13) exist for year-end audit adjustments and topside entries after the normal calendar closes - they should contain controller-approved adjustments only, never routine AP activity. Unexplained period-13 entries mean someone is using the audit window as an overflow lane; lock it down to named users.

Legitimate: posting an invoice to a still-open prior period because the expense belongs there - that's correct period assignment, not backdating. Control failure: dating postings into closed or reported periods to move results, or routinely backposting because processing is slow. Policy: posting date follows the expense period while the period is open; after lock, accrue or adjust formally.

Stampli validates invoices against current ERP structure and posting rules before export, so period conflicts surface as actionable errors AP can fix and retry - not as silent failures discovered at close. The ERP stays in charge of period control; Stampli's job is making sure what AP sends will land cleanly, and showing the posting status of every invoice in real time.