OpenText VIM at year-end: clear the workflow before the vendor period closes

For a company on a calendar fiscal year, the December AP close is about nine weeks out. The invoices that cause trouble at year-end are rarely the posted ones. They're the ones still in OpenText VIM: scanned, extracted, perhaps half approved, and not yet in the general ledger. Late October is the time to decide how those get handled, before the volume arrives.

What's in SAP, and what isn't. Be exact about states, because each behaves differently at close.

  • Still in VIM document processing, before any SAP document exists: not in SAP Financial Accounting at all. It's a work item and an image.

  • Parked: it has an SAP document number, but SAP's own course material is plain that parking updates no transaction figures. The liability isn't on the vendor account or in the GL until it posts. (Amounts from parked documents are available to some real-time evaluations, such as the advance return for tax on sales and purchases.)

  • Posted with a payment block: on the books. The block stops payment, not the posting.

In many VIM designs a non-PO invoice waits for approval as a parked document, so a December approval backlog is also a gap in the ledger. Confirm whether your design parks before or after approval. It decides which queue the controller watches.

Posting periods close by account type. In S/4HANA, periods open and close through a posting period variant (OB52, or the Manage Posting Periods app from S/4HANA 1809), and they can be handled differently by account type. SAP's own example is the AP case: postings to customer accounts may be allowed while postings to vendor accounts are restricted. Once AP closes the vendor account type for December, a VIM invoice dated in December can't post to it. Then someone chooses. Post in January with a January posting date, or post into December through the restricted interval, which SAP recommends controlling with period interval 1 and authorization object F_BKPF_BUP. That's the controller's call. It shouldn't fall to whoever is working the exception queue on 4 January.

Five decisions, with owners. The owners are our view; adjust them to your org chart, but name someone.

  1. Cut-off rule (controller). Which date decides the period: invoice date, receipt date or goods receipt? Put the rule in the AP close calendar and check that VIM's posting date default matches it.

  2. Accrual for what's still in VIM (controller with AP). Received but unposted invoices are an amount the GL can't see. Decide whether to accrue from a VIM list of open items, from GR/IR, or both, and how you avoid counting one invoice twice.

  3. Approval cover (AP lead). Set a December date by which pending approvals are chased, and decide who covers for approvers on holiday. Substitutes only help if someone sets them up before people leave.

  4. The exception queue (AP lead with purchasing). Price and quantity exceptions waiting on a buyer age fastest in December. Name a buyer contact per purchasing group for the last two weeks.

  5. The first week of January (AP lead). Who works the invoices that couldn't post, with which posting date, and who signs off the list.

The list you want on 31 December. One view of everything in VIM that isn't posted, split by state (in processing, parked, waiting for approval, in exception), with amount, company code and age. Agree before December what the controller reads and on which day. The discipline from separating channels before you trust the score applies here too: one blended count can't stand in for four different states.

And don't tune VIM in the last two weeks of December. Hold business rule changes unless a fix is urgent, and log anything that does change, so January's questions have answers.

McCloy Data

Thought leadership on OpenText, SAP, and practical content and finance automation - from the McCloy Data team.

https://www.mccloydata.com
Previous
Previous

Copilot Studio agents: decide which SharePoint sites they may read

Next
Next

SAP SuccessFactors and OpenText: Basic Auth ends 21 May 2027, plan the OAuth move