AR-05: AR Period Close Readiness Diagnostic

The AR period close has a different topology than the AP period close — it has more moving parts and more potential blocking conditions. Where the AP close primarily concerns invoice validation and payment confirmation, the AR close requires that all of the following be true simultaneously: all AR transactions are accounted, all receipts are posted, all adjustments are approved, revenue recognition has been run for the period, the AR-to-GL transfer is complete, and the XLA accounting events have no errors. These conditions are managed through different concurrent programs, different setup areas, and different Oracle modules — and each one can fail independently.

Revenue recognition is the most operationally complex AR close requirement. Transactions governed by revenue scheduling rules — for example, a software license that recognizes 25% of revenue per quarter over four quarters — must have the Run AutoAccounting and Revenue Recognition programs run before the period can be fully closed. If a transaction was modified after revenue was partially recognized — an amendment, a credit memo, or a price correction — the revenue schedule needs to be rebuilt. In environments where Oracle Contracts or Order Management drives AR transactions, this process can involve hundreds of active revenue schedules that need to be verified against their expected recognition amounts.

The AR adjustment approval process is a hidden close blocker that is frequently overlooked. Adjustments to open invoices — write-offs, minor balance corrections, early payment discounts — are entered in Oracle AR and held in a pending status until they are approved by an authorized approver. If an approver has been out of office, if the approval limit configuration has changed, or if the adjustment was submitted but the approval notification was missed, the adjustment sits in PENDING status and prevents the period from closing. AR-05 surfaces all pending adjustments with the approver, the amount, and the age of the pending request.

AR-05 runs a complete period-close readiness scan for AR — period status across AR/GL/XLA, unaccounted transaction count and amount, unposted receipt count, incomplete transaction batch status, revenue recognition completeness by schedule rule, pending adjustment approvals with approver and age, and the AR-to-GL transfer status. It produces a single prioritized report ordered by the sequence in which blockers must be resolved.

Period Status

AR period status in GL_PERIOD_STATUSES. XLA period status. Subledger accounting period open/closed. Future period entry dates.

Unposted Receipts

Receipts confirmed but not posted to GL — ACCOUNTED_FLAG = 'N'. Reversed receipts not yet posted. On-account receipts not applied.

Unaccounted Transactions

Invoices, credit memos, and adjustments with ACCOUNTED_FLAG = 'N'. XLA events in ERROR or UNPROCESSED status. Events older than 24 hours in unprocessed status.

Incomplete Batches

Open batches not yet closed — blocking period reconciliation. Batch control amounts not matching transaction sums. AutoInvoice batches with failed lines.

Revenue Recognition

Revenue recognition program run status for the period. Deferred revenue schedules not yet recognized. Contingency flag invoices blocking recognition.

Adjustment Approvals

Adjustments in PENDING APPROVAL status that need to be approved or rejected before close. Adjustment amount exceeding approval limit thresholds.

════════════════════════════════════════════════════════════
  ORACLE EBS R12 — AR PERIOD CLOSE READINESS DIAGNOSTIC
════════════════════════════════════════════════════════════
  Period             : FEB-2026
  Ledger             : US Primary Ledger
  Operating Unit     : US Operations OU
  Case Number        : AR-335420
  Report Date        : 25-FEB-2026 15:45:10
════════════════════════════════════════════════════════════

[ SECTION 1 — PERIOD STATUS ]                STATUS: ✓ PASS
────────────────────────────────────────────────────────────
  AR Period          : FEB-2026 — OPEN ✓
  GL Period          : FEB-2026 — OPEN ✓

[ SECTION 2 — UNACCOUNTED TRANSACTIONS ]     STATUS: ✗ FAIL
────────────────────────────────────────────────────────────
  Unaccounted Trx    : 9 transactions — $184,200 ✗
  Unposted Receipts  : 4 receipts — $92,100 ✗
  ✗ FAIL: Create Accounting must run before period close

[ SECTION 3 — REVENUE RECOGNITION ]          STATUS: ⚠ WARNING
────────────────────────────────────────────────────────────
  Schedules Complete : 42 / 44 ✓
  Incomplete Schedules : 2 — revenue not fully recognized for FEB-2026
  ⚠ WARNING: Run Revenue Recognition for 2 incomplete schedules
  Transaction IDs    : 1881200, 1882440

[ SECTION 4 — ADJUSTMENTS PENDING APPROVAL ] STATUS: ✗ FAIL
────────────────────────────────────────────────────────────
  ✗ 3 adjustments in PENDING status — total $8,400
  Oldest Pending     : 12 days — Approver: J.DAVIDSON
  ✗ FAIL: Pending adjustments block period close

[ SECTION 5 — AR-TO-GL TRANSFER ]            STATUS: ✓ PASS

════════════════════════════════════════════════════════════
  CLOSE READINESS SUMMARY
════════════════════════════════════════════════════════════
  PERIOD CANNOT CLOSE — 3 blocking conditions
  1. Run Create Accounting for 9 transactions and 4 receipts
  2. Obtain approval for 3 pending adjustments (J.DAVIDSON)
  3. Run Revenue Recognition for transactions 1881200, 1882440
════════════════════════════════════════════════════════════

KB-AR-335420-001 · Script: AR-05

AR Period FEB-2026 Close Blocked — Unaccounted Transactions, Pending Adjustments, Incomplete Revenue Recognition

Module: Accounts Receivable
Platform: EBS R12.2.10
Status: RESOLVED

Symptom

Close Receivables Period for FEB-2026 blocking. 9 unaccounted transactions ($184,200), 4 unposted receipts ($92,100), 3 pending adjustments awaiting J.Davidson approval, and 2 incomplete revenue recognition schedules identified as blocking conditions.

Root Cause

Unaccounted transactions: Create Accounting was not submitted after the last batch of transactions was entered on 24-FEB. Pending adjustments: 3 write-off adjustments submitted 12 days ago — J.Davidson on vacation, no delegate approver configured. Revenue recognition: 2 amended transactions had revenue schedules rebuilt but Recognition program not rerun.

Tables Affected

RA_CUSTOMER_TRX_ALL — POSTING_CONTROL_ID IS NULL (9 unaccounted, period FEB-2026)
AR_ADJUSTMENTS_ALL — STATUS = PENDING (3 adjustments, approver JDAVIDSON)
RA_REVENUE_ADJUSTMENTS_ALL — COMPLETE_FLAG = N (2 revenue schedules)

Fix Applied

Create Accounting submitted for AR — 9 transactions and 4 receipts accounted. J.Davidson delegation updated — R.Martinez approved 3 pending adjustments. Revenue Recognition run for transactions 1881200 and 1882440. Period closed 25-FEB-2026 17:10.

Prevention

Create Accounting should be scheduled to run automatically after each batch entry job. Adjustment approver delegation should be configured for all approvers before leave. AR-05 should run at period day-minus-3. Revenue Recognition should run nightly for all active schedules.

Table / View	Schema	Purpose in Diagnostic
RA_CUSTOMER_TRX_ALL	AR	Transaction accounting status
AR_CASH_RECEIPTS_ALL	AR	Receipt posting status
AR_ADJUSTMENTS_ALL	AR	Adjustments pending approval
RA_BATCHES	AR	Batch status and control amounts
XLA_EVENTS	XLA	Accounting event status
XLA_AE_HEADERS	XLA	Accounting header errors
RA_REVENUE_ADJUSTMENTS_ALL	AR	Revenue recognition schedule status
GL_PERIOD_STATUSES	GL	Period open/closed status
AR_DEFERRED_REVENUE_ALL	AR	Deferred revenue balances

How Every Fix Decision Is Made

Before any data is modified in a production Oracle database, AP-01 walks through a four-stage decision process. Every condition identified by the diagnostic maps to exactly one resolution path.

First Option — Always

Can the front end fix this?

Oracle's own forms and concurrent programs are always the first option. If the condition can be corrected through Oracle's standard UI — a form, a concurrent program, a setup screen — that path is taken first. No consultant SQL required, no database risk, and the fix is fully supported by Oracle. The diagnostic identifies these conditions explicitly and states the exact front-end navigation path.

✓ Functional Fix

When Front End Is Not Available

Is a direct data fix safe to apply?

When the front-end path is unavailable or would require an unacceptable volume of manual steps, a direct fix is evaluated against explicit criteria. All of the following must be true before proceeding:

→The fix mirrors exactly what Oracle's own code would have done if the underlying condition were corrected

→All dependent tables have been identified and will be updated in the same transaction

→The fix is fully reversible — a single INSERT from the backup table restores the original state

→The environment patch level has been confirmed against the fix logic version

⚡ Direct Fix

Hard Stops — No Exceptions

Does this require Oracle Support?

Certain table areas are never touched directly, regardless of how well the underlying structure is understood. The diagnostic flags these conditions and generates the Service Request documentation:

✗XLA subledger tables — XLA_EVENTS, XLA_AE_HEADERS — incorrect changes corrupt the subledger audit trail in ways undetectable until period close fails or an auditor requests a reconciliation

✗Workflow engine tables — WF_ITEMS, WF_ITEM_ACTIVITY_STATUSES — ad-hoc DML can corrupt the workflow engine state instance-wide

✗Recurring conditions after a fix — indicates a code defect, not a data error. Documented and submitted as a Service Request with a reproducible test case

⚠ Oracle Support

For All Approved Direct Fixes

Backup → Execute → Verify → Document

A timestamped backup table is created and row-count verified before the first UPDATE fires. Explicit parameter confirmation is required — the script will not self-execute. After execution, a verification query confirms the expected state. A complete change record — rows affected, before and after values, database username, timestamp — is written to the FIX_BACKUP_REGISTRY and becomes the primary artifact in the knowledge base entry for this incident.

📋 Documented

Condition Identified	Resolution Path	Notes
Unaccounted AR transactions — not sent to Create Accounting	Functional First	Submit Create Accounting for the Receivables application and current period. AR-05 provides the exact parameters. Accounting errors after Create Accounting are categorized separately.
Unposted receipts — receipts in incomplete status	Functional First	Submit Post QuickCash or confirm that the receipt batch is in a CLOSED status. AR-05 identifies unposted receipts by batch and age with the specific program to run for each receipt type.
Revenue recognition incomplete — active schedules not run	Functional First	Submit the Revenue Recognition concurrent program for the current period. AR-05 identifies the specific transaction IDs with incomplete schedules and the revenue amounts that have not yet been recognized.
Pending adjustments — awaiting approval	Functional First	Escalate to the approver or configure a delegate approver via Receivables > Setup > System Options > Approvals. AR-05 identifies each pending adjustment, the approver, the amount, and the age of the pending request.
AR-to-GL transfer incomplete — journals not transferred	Functional First	Submit Transfer to General Ledger concurrent program. AR-05 identifies which periods have untransferred AR journals and provides the exact submission parameters.
XLA events in ERROR — AR accounting blocked	Oracle Support	AR XLA accounting errors are investigated via the Create Accounting Execution Report. Root cause is typically an invalid GL account. XLA tables are never modified directly — error correction goes through the AR transaction or setup.
Incomplete transaction batches — batches not closed	Functional First	Close open batches via Receivables > Control > Batches. AR-05 identifies all batches in OPEN or INCOMPLETE status with transaction count and amount.
GL date in closed period — AR transaction cannot be accounted	Direct Fix	AR-05 identifies the next open period, generates the GL date correction on RA_CUSTOMER_TRX_ALL with full backup. Pre-flight confirms transaction is unaccounted and no XLA event is active.

Safeguards

Nothing Executes Without a Safety Net

Before any data fix runs, the script verifies pre-flight conditions and creates a complete verified backup. If any check fails, the script aborts. There is no partial execution path.

Pre-Flight Checks — All Must Pass

✓

POSTED_FLAG = 'N'

Will not modify a posted transaction under any circumstances

✓

ACCOUNTING_EVENT_ID IS NULL

Will not modify rows with an active or pending XLA accounting event

✓

No active database lock

Checks V$LOCK — will not proceed if another session holds a lock on target rows

✓

CONS_BACKUP schema writable

Backup schema must be accessible before any DML is permitted

✓

Explicit confirmation required

Script outputs a confirmation prompt — DML does not execute until consultant enters the case number as the execution parameter

Backup Methodology

Before the first UPDATE fires, the script creates a complete copy of every row to be modified. Tables are named CONS_BACKUP.<TABLE>_<CASE#> and persist permanently after execution.

RA_CUSTOMER_TRX_ALL

AR_CASH_RECEIPTS_ALL

AR_ADJUSTMENTS_ALL

XLA_EVENTS

Row count verified after backup creation. If backup fails for any reason the script aborts without executing any DML. Rollback is a single INSERT from the backup table. No reconstruction required.

AR-05 — Pre-Flight & Backup Verification

════════════════════════════════════════════════════════════
  PRE-FLIGHT SAFETY CHECK
════════════════════════════════════════════════════════════
  Period             : FEB-2026
  AR Period Status   : OPEN ✓
  CONS_BACKUP Schema : Accessible ✓
  Session Lock Check : No locks on target rows ✓
────────────────────────────────────────────────────────────
  ALL PRE-FLIGHT CHECKS PASSED
════════════════════════════════════════════════════════════
  Creating : CONS_BACKUP.RA_CUSTOMER_TRX_ALL_335420
  Rows     : 9 rows backed up ✓
  Creating : CONS_BACKUP.AR_ADJUSTMENTS_ALL_335420
  Rows     : 3 rows backed up ✓
  Registry : FIX_BACKUP_REGISTRY — ID 3108 created ✓
────────────────────────────────────────────────────────────
  BACKUP COMPLETE
════════════════════════════════════════════════════════════
  Enter case number to confirm : 335420
  Confirmed.
════════════════════════════════════════════════════════════

Knowledge Base

Every Execution Produces a Record

The knowledge base article is generated automatically from the script's execution output. No manual documentation required. It becomes the institutional record — for the team, for auditors, and for every future engagement in the same environment.

Zero Manual Effort

Every field — environment, tables, before/after values, backup reference, root cause, prevention — is generated from actual execution output. Nothing is written by hand.

Patterns Surface Over Time

The first engagement produces findings. The third produces patterns. Recurring conditions that are invisible as individual incidents become obvious as knowledge base trends.

Survives Staff Turnover

The knowledge base is an institutional record of the Oracle environment. A new manager, a new DBA, or an external auditor can read exactly what happened, what was done, and what prevents recurrence.

KB-AR-335420-001

AR Period FEB-2026 Close Blocked — Unaccounted Transactions, Pending Adjustments, Incomplete Revenue Recognition

EBS R12.2.10 · Accounts Receivable

● RESOLVED

Symptom

Root Cause

Tables

RA_CUSTOMER_TRX_ALL — POSTING_CONTROL_ID IS NULL (9 unaccounted, period FEB-2026)
AR_ADJUSTMENTS_ALL — STATUS = PENDING (3 adjustments, approver JDAVIDSON)
RA_REVENUE_ADJUSTMENTS_ALL — COMPLETE_FLAG = N (2 revenue schedules)

Fix Applied

Prevention

R12 Guide (PDF)	Title & Chapter	Detail
120arig.pdf	Oracle Receivables Implementation Guide — Ch. 2: Accounting System Options	pp. 2-24 to 2-27: Accounting options for unposted transactions blocking AR period close
120ceug.pdf	Oracle Cash Management User Guide — Ch. 2: AP/AR for CE Integration	pp. 2-12 to 2-16: Bank reconciliation completion as AR close prerequisite
120arig.pdf	Oracle Receivables Implementation Guide — Setup Checklist	Complete AR setup verification for period-end close readiness

AR Period Close Readiness Diagnostic

Why This Fails — and What It Costs

What This Script Diagnoses

What the Report Looks Like

The Four-Layer Architecture in AR-05

Backup & Rollback for AR-05

Tables Backed Up — AR-05

Pre-Flight Safety Guards

FIX_BACKUP_REGISTRY Entry

Auto-Generated Knowledge Base Article

Most Common Issues Detected by AR-05

Unaccounted AR Transactions

XLA Events in ERROR

Revenue Recognition Not Run

Adjustments Pending Approval

Tables & Views Examined

How Every Fix Decision Is Made

Nothing Executes Without a Safety Net

Every Execution Produces a Record

Oracle Documentation References

Ready to Resolve This in Your Environment?

Why This Fails — and What It Costs

What This Script Diagnoses

What the Report Looks Like

The Four-Layer Architecture in AR-05

Backup & Rollback for AR-05

Tables Backed Up — AR-05

Pre-Flight Safety Guards

FIX_BACKUP_REGISTRY Entry

Auto-Generated Knowledge Base Article

Most Common Issues Detected by AR-05

Unaccounted AR Transactions

XLA Events in ERROR

Revenue Recognition Not Run

Adjustments Pending Approval

Tables & Views Examined

How Every Fix Decision Is Made

Nothing Executes Without a Safety Net

Every Execution Produces a Record

Oracle Documentation References

Related Diagnostic Scripts

AR Transaction Validation

Revenue Recognition Diagnostic

AP Period Close Readiness

GL Period Close Readiness

Ready to Resolve This in Your Environment?