AP-03 EBS R12.x Accounts Payable Tier 2 Data Fix

Supplier & Vendor Master Health Diagnostic

Complete vendor master health check — active status, site configuration, bank accounts, payment terms, 1099 setup, holds, and duplicate supplier detection across TCA.

PlatformOracle EBS R12.x
Input RequiredVendor ID or Vendor Number
Diagnostic Checks30+
Data Sources9 Oracle tables
Fix Options5 guided fixes
Backup CreatedYes — Automatic

Why This Fails — and What It Costs

Vendor master data problems in Oracle EBS are among the most pervasive and most difficult to diagnose because the vendor record spans four separate Oracle modules — the AP supplier tables, the TCA party model in HZ, the IBY payment instrument tables, and the ZX tax profile. A symptom that presents as a payment failure may have its root cause in a missing IBY bank account assignment. A symptom that presents as a 1099 reporting discrepancy may have its root cause in an incomplete ZX_PARTY_TAX_PROFILE record. The AP team sees the payment error. The Tax team sees the 1099 gap. Neither team has full visibility across the complete vendor record structure.

The most operationally damaging vendor master condition is a vendor placed on hold without a clear release path. Oracle EBS supports multiple hold types at the vendor level — AP_HOLDS_ALL records a hold on an existing invoice, but a vendor-level hold set in AP_SUPPLIERS.HOLD_FLAG blocks all future invoice entry for that vendor across every operating unit. In environments where the AP team and the Purchasing team use different forms, it is common for a vendor hold to be placed by one team and released by another — with neither team realizing the hold persists because it is stored in a different field than the one they checked.

Duplicate vendor records compound the problem. When the same supplier exists under two or more AP_SUPPLIERS records — often created because the Purchasing team created a new vendor rather than searching for the existing one — invoices accumulate against both records. 1099 reportable amounts are split between them, neither reaching the reporting threshold individually, resulting in missed filings and potential IRS penalties. Vendor merge is the correct resolution, but it requires identifying all transactions referencing both vendor IDs across AP, PO, and potentially FA and PA before the merge is executed.

AP-03 examines the complete vendor record — header status and hold flags, all vendor sites across operating units, bank account existence and active status in IBY, payment terms and pay group configuration, 1099 type and Federal Tax ID completeness, and duplicate detection by name similarity, bank account, and tax ID. It identifies every condition that will block invoice entry, payment processing, or correct tax reporting — and provides the exact resolution path for each one.

What This Script Diagnoses

AP-03 systematically investigates every major condition that can cause the issue this diagnostic targets. Below is the complete coverage breakdown.

Vendor Active Status
Vendor header active status, end date, hold type. All vendor sites — active status, payment site, primary pay site, purchasing site. Operating unit site assignments.
Bank Account Configuration
Bank account existence per vendor site. Account active status. Payment method enabled. IBAN completeness for international vendors. Prenote status for EFT.
Payment Terms & Groups
Payment terms validity and active status. Pay group assignment. Discount terms. Hold type and reason. Offset account setup for debit memos.
1099 / Tax Reporting
1099 type assignment (MISC, NEC, INT). Federal ID number presence. 1099 threshold tracking. State income tax reporting setup. Exclusion flags.
Duplicate Detection
Duplicate vendor detection by name similarity, tax ID, and bank account across HZ_PARTIES and AP_SUPPLIERS. Merge candidate identification. Duplicate site detection.

What the Report Looks Like

Representative output showing the diagnostic running against a real-world scenario. The script identifies every condition, states the root cause, and generates the fix.

AP-03 — AP-03 Diagnostic Report
════════════════════════════════════════════════════════════
  ORACLE EBS R12 — SUPPLIER HEALTH DIAGNOSTIC
════════════════════════════════════════════════════════════
  Vendor ID          : 10892
  Vendor Name        : Pacific Rim Consulting LLC
  Operating Unit     : US West OU
  Case Number        : 834291
  Report Date        : 21-FEB-2026 11:45:03
════════════════════════════════════════════════════════════

[ SECTION 1 — VENDOR HEADER STATUS ]         STATUS: ✗ FAIL
────────────────────────────────────────────────────────────
  Vendor Active      : YES ✓
  Vendor Hold Flag   : Y ✗ — Vendor on hold
  Hold Type          : PAYMENT
  Hold Set By        : JSMITH
  Hold Date          : 15-JAN-2026
  ✗ FAIL: Vendor hold blocking all invoice entry and payment
  Fix                : Suppliers > Entry > Hold: set to N after dispute resolution

[ SECTION 2 — VENDOR SITES ]                 STATUS: ⚠ WARNING
────────────────────────────────────────────────────────────
  Total Sites        : 3
  US-PRIMARY         : ACTIVE — Pay Site ✓
  US-REMIT           : ACTIVE ✓
  US-OLD             : INACTIVE — has 2 open invoices ⚠
  ⚠ WARNING: Inactive site US-OLD referenced by open invoices

[ SECTION 3 — BANK ACCOUNT ]                 STATUS: ✓ PASS
────────────────────────────────────────────────────────────
  Bank Account       : Wells Fargo x7821 — ACTIVE ✓
  Payment Method     : EFT ✓

[ SECTION 4 — 1099 SETUP ]                   STATUS: ✗ FAIL
────────────────────────────────────────────────────────────
  1099 Type          : MISC
  Federal Tax ID     : MISSING ✗
  YTD Reportable Amt : $48,200.00
  ✗ FAIL: Federal Tax ID missing — 1099 reporting will fail at year-end

[ SECTION 5 — DUPLICATE DETECTION ]          STATUS: ⚠ WARNING
────────────────────────────────────────────────────────────
  ⚠ Possible duplicate: Vendor 10445 'Pacific Rim Consulting' — same tax ID

════════════════════════════════════════════════════════════
  DIAGNOSTIC SUMMARY
════════════════════════════════════════════════════════════
  3 conditions require resolution before vendor is fully operational
  1. Release vendor hold (PAYMENT) — contact JSMITH for authorization
  2. Add Federal Tax ID to vendor tax profile
  3. Review duplicate vendor 10445 for merge
════════════════════════════════════════════════════════════

The Four-Layer Architecture in AP-03

1
Diagnostic Engine
Runs 30+ checks across vendor header status and hold flags, all vendor sites per OU, IBY bank account existence and active status, payment terms and pay group, 1099 type and Federal Tax ID, and duplicate detection across HZ_PARTIES.
2
Backup Created
Before any vendor record is modified, CONS_BACKUP.AP_SUPPLIERS_<case#>, AP_SUPPLIER_SITES_ALL_<case#>, and ZX_PARTY_TAX_PROFILE_<case#> are created and row counts verified.
3
Guided Data Fix
Most vendor conditions resolve through Oracle's own Supplier form. For direct-fixable data issues — inactive site with open invoices, orphaned tax profile records — AP-03 generates the fix with full backup. Explicit COMMIT required.
4
KB Article Generated
Complete KB article generated — vendor ID, conditions found, hold details, 1099 status, duplicate candidates, resolution path taken. Upload directly to your knowledge base.

Backup & Rollback for AP-03

Every table touched by AP-03 data fixes is backed up before the first UPDATE fires. Backup is verified by row count. One script restores the original state if needed.

Tables Backed Up — AP-03

CONS_BACKUP.AP_SUPPLIERS_<case#> CONS_BACKUP.AP_SUPPLIER_SITES_ALL_<case#> CONS_BACKUP.IBY_EXT_BANK_ACCOUNTS_<case#> CONS_BACKUP.ZX_PARTY_TAX_PROFILE_<case#>

Backup happens before any DML. Script aborts if backup creation fails.

Pre-Flight Safety Guards

POSTED_FLAG = 'N'Required ✓
ACCOUNTING_EVENT_ID IS NULLRequired ✓
No active session lockChecked ✓
CONS_BACKUP schema accessibleVerified ✓

FIX_BACKUP_REGISTRY Entry

REGISTRY_ID<auto-generated>
CASE_NUMBER<consultant case#>
SOURCE_TABLE<table modified>
ROWS_BACKED_UP<row count>
BACKUP_VERIFIEDYES ✓
ROLLBACK_SQLStored as CLOB
STATUSACTIVE
ENVIRONMENTPRODUCTION

Auto-Generated Knowledge Base Article

This article is produced automatically at the end of every AP-03 execution — written from actual run output. No manual documentation required.

KB-AP-834291-001 · Script: AP-03
Vendor Hold Blocking Invoice Entry — Missing Federal Tax ID for 1099 Reporting
AP team unable to enter new invoices for vendor 10892 Pacific Rim Consulting LLC. Existing invoices blocked from payment selection. 1099 reporting flagged as at risk for year-end — $48,200 YTD with no Federal Tax ID on file.
Vendor hold flag set to Y on 15-JAN-2026 by JSMITH during a payment dispute. Hold was not released after dispute resolution. Federal Tax ID was never entered at vendor creation — vendor was set up as a 1099 MISC vendor but the ZX_PARTY_TAX_PROFILE.TAX_IDENTIFICATION_NUM field was left blank.
AP_SUPPLIERS — HOLD_FLAG, VENDOR_ID (Vendor: 10892)
ZX_PARTY_TAX_PROFILE — TAX_IDENTIFICATION_NUM (Party: HZ party for vendor 10892)
Vendor hold released via Suppliers > Entry (authorized: AP Manager, 21-FEB-2026). Federal Tax ID entered in Oracle E-Business Tax > Party Tax Profiles. Duplicate vendor 10445 referred to Procurement for merge review.
Vendor creation checklist should require Federal Tax ID for all 1099-type vendors before record is saved. AP-03 vendor health check should be run quarterly to surface hold flags, missing tax setup, and duplicate candidates before year-end.
APSupplier MasterVendor Hold1099Federal Tax IDDuplicate VendorHZ_PARTIESEBS R12.2

Most Common Issues Detected by AP-03

Status

Vendor on Hold

Vendor has an active hold preventing invoice entry or payment. AP-03 identifies the hold type, who placed it, the date, and the release navigation path.

Bank Setup

No Active Bank Account

Vendor site has no active bank account assigned — blocking EFT payments. AP-03 identifies missing bank setup and provides the TCA party bank account navigation path.

Tax Setup

Missing Federal ID for 1099

1099 vendor does not have a Federal Tax ID populated. AP-03 flags the vendor, current reportable amount YTD, and the setup correction path.

Duplicate

Duplicate Vendor Detected

Same vendor appears under two or more supplier records. AP-03 identifies matches by name similarity, bank account, or tax ID and flags for supplier merge review.

Tables & Views Examined

Table / ViewSchemaPurpose in Diagnostic
AP_SUPPLIERS AP Vendor header — active status, hold, tax ID
AP_SUPPLIER_SITES_ALL AP Vendor sites — active status, OU, payment terms
IBY_EXT_BANK_ACCOUNTS IBY Vendor bank accounts
HZ_PARTIES HZ TCA party records for duplicate detection
HZ_PARTY_SITES HZ Party site addresses
AP_HOLDS_ALL AP Vendor-level holds
PO_VENDORS PO Legacy vendor view
IBY_PMT_INSTR_USES_ALL IBY Payment instrument assignments
ZX_PARTY_TAX_PROFILE ZX Tax profile for 1099 setup
Decision Framework

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.

1
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
2
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
3
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 tablesXLA_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 tablesWF_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
4
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
Vendor hold flag set — blocking all invoice entry Functional First Release via Suppliers > Entry > set HOLD_FLAG to N. AP-03 identifies who set the hold, when, and the hold type so authorization can be obtained before release.
Inactive vendor site referenced by open invoices Functional First Reactivate the site via Suppliers > Sites if still valid, or transfer open invoices to the correct active site via invoice correction. AP-03 identifies all invoices referencing the inactive site.
Missing Federal Tax ID on 1099 vendor Functional First Enter the Federal Tax ID in Oracle E-Business Tax > Party Tax Profiles for the TCA party linked to the vendor. AP-03 identifies the HZ_PARTY_ID and the navigation path.
No active bank account — EFT payments will fail Functional First Create or reactivate the bank account in IBY_EXT_BANK_ACCOUNTS via Suppliers > Banking. AP-03 identifies whether the account exists but is inactive, or is missing entirely.
Prenote status FAILED — EFT prenote rejected by bank Direct Fix AP-03 resets IBY_EXT_BANK_ACCOUNTS.PRENOTE_STATUS to SENT with full backup, allowing a new prenote cycle to initiate on the next payment run.
Duplicate vendor detected — same tax ID or bank account Functional First Duplicate vendor merge must be initiated via Purchasing > Suppliers > Merge. AP-03 identifies all transactions referencing both vendor IDs to validate merge safety before execution.
Pay group invalid or not assigned Functional First Assign a valid pay group via Suppliers > Entry > Payment Details. AP-03 identifies the current pay group value and valid options from AP_LOOKUP_CODES.
Vendor site OU assignment missing Functional First Add the operating unit assignment via Suppliers > Sites > Operating Units. AP-03 identifies which OUs are missing the site assignment based on open POs and invoices.
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.

AP_SUPPLIERS
AP_SUPPLIER_SITES_ALL
IBY_EXT_BANK_ACCOUNTS
ZX_PARTY_TAX_PROFILE
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.
AP-03 — Pre-Flight & Backup Verification
════════════════════════════════════════════════════════════
  PRE-FLIGHT SAFETY CHECK
════════════════════════════════════════════════════════════
  Vendor ID          : 10892
  POSTED Invoices    : None in scope — safe to proceed ✓
  CONS_BACKUP Schema : Accessible ✓
  Session Lock Check : No locks detected ✓
────────────────────────────────────────────────────────────
  ALL PRE-FLIGHT CHECKS PASSED — Ready to create backup
════════════════════════════════════════════════════════════
  Creating : CONS_BACKUP.AP_SUPPLIERS_834291
  Rows     : 1 row backed up ✓ Verified
  Creating : CONS_BACKUP.ZX_PARTY_TAX_PROFILE_834291
  Rows     : 1 row backed up ✓ Verified
  Registry : FIX_BACKUP_REGISTRY — ID 2041 created ✓
────────────────────────────────────────────────────────────
  BACKUP COMPLETE — Rollback available via single INSERT
════════════════════════════════════════════════════════════
  CONFIRMATION REQUIRED BEFORE UPDATE EXECUTES
  Enter case number to confirm : 834291
  Confirmed. Executing fix...
════════════════════════════════════════════════════════════
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-AP-834291-001
Vendor Hold Blocking Invoice Entry — Missing Federal Tax ID for 1099 Reporting
EBS R12.2.10 · Accounts Payable
● RESOLVED
Symptom
AP team unable to enter new invoices for vendor 10892 Pacific Rim Consulting LLC. Existing invoices blocked from payment selection. 1099 reporting flagged as at risk for year-end — $48,200 YTD with no Federal Tax ID on file.
Root Cause
Vendor hold flag set to Y on 15-JAN-2026 by JSMITH during a payment dispute. Hold was not released after dispute resolution. Federal Tax ID was never entered at vendor creation — vendor was set up as a 1099 MISC vendor but the ZX_PARTY_TAX_PROFILE.TAX_IDENTIFICATION_NUM field was left blank.
Tables
AP_SUPPLIERS — HOLD_FLAG, VENDOR_ID (Vendor: 10892)
ZX_PARTY_TAX_PROFILE — TAX_IDENTIFICATION_NUM (Party: HZ party for vendor 10892)
Fix Applied
Vendor hold released via Suppliers > Entry (authorized: AP Manager, 21-FEB-2026). Federal Tax ID entered in Oracle E-Business Tax > Party Tax Profiles. Duplicate vendor 10445 referred to Procurement for merge review.
Prevention
Vendor creation checklist should require Federal Tax ID for all 1099-type vendors before record is saved. AP-03 vendor health check should be run quarterly to surface hold flags, missing tax setup, and duplicate candidates before year-end.
Tags
APSupplier MasterVendor Hold1099Federal Tax IDDuplicate VendorHZ_PARTIESEBS R12.2

Oracle Documentation References

R12 Guide (PDF)Title & ChapterDetail
120apug.pdfOracle Payables User's Guide — Chapter 2: SuppliersCh. 2: Supplier setup, supplier holds, payment information, and supplier merge program
120apug.pdfOracle Payables User's Guide — Ch. 2: Reviewing and Adjusting Supplierspp. 2-33 to 2-46: Identifying duplicate suppliers, supplier merge, and supplier audit report
120funmo.pdfOracle Applications Multiple Organizations Implementation GuideCh. 2: Operating unit partitioning of supplier data for access control escalations

Ready to Resolve This in Your Environment?

AP-03 is one of 65 diagnostic scripts covering every major Oracle EBS and Fusion module. William A. Green Consulting runs the script in your environment, applies guided data fixes, and builds the knowledge base that prevents the same issues from recurring.

Schedule a Discovery Call → ← View All 65 Scripts

See this script run autonomously — Oracle AI Platform →