Vendor master data sync creates duplicate records in accounts payable

ERP Oracle Fusion Cloud
, , , , , , , ,
1

We’re experiencing duplicate vendor records after running FBDI bulk loads for vendor master data in our accounts payable module. The duplicates seem to bypass our Tax ID validation and are causing payment routing failures.

Our FBDI template includes Tax ID field mapping, but we’re still getting duplicates with slightly different formats (some with hyphens, some without). We’ve also noticed issues with vendor hierarchies - parent-child relationships aren’t being maintained correctly.

Has anyone configured FBDI duplicate detection properly? We need pre-validation reporting to catch these before they hit the system. Also wondering if HDL would handle vendor hierarchies better than FBDI for our use case.

Any guidance on configuring duplicate detection rules and proper Tax ID format validation would be greatly appreciated.

system 2

The issue you’re facing requires addressing multiple configuration areas systematically. Let me walk through the complete solution:

FBDI Duplicate Detection Configuration: Navigate to Setup and Maintenance > Search: Manage Supplier Duplicate Prevention Rules. Configure matching attributes to include:

  • Tax Registration Number (with normalization)
  • Supplier Name (fuzzy matching at 85% threshold)
  • Address Line 1

Enable the ‘Normalize Tax IDs’ option which strips hyphens, spaces, and leading zeros before comparison.

Tax ID Field Mapping and Format Validation: In your FBDI template, add a pre-processing step to normalize Tax IDs:


TAX_ID_NORMALIZED = REGEXP_REPLACE(TAX_ID, '[^0-9]', '')
VALIDATION_CHECK = LENGTH(TAX_ID_NORMALIZED) = 9

Create a custom validation rule in Application Composer that enforces this format before allowing supplier creation.

HDL vs FBDI for Vendor Hierarchies: For complex hierarchies, HDL is superior because it maintains referential integrity through explicit parent references. Use HDL for hierarchy loads:


MERGE|Supplier|SupplierNumber|ParentSupplierNumber
MERGE|SUP001|SUP001|NULL
MERGE|SUP001-01|SUP001-01|SUP001

FBDI processes records independently and can create orphaned children if parent records fail validation.

Pre-Validation Reporting for Duplicates: Create a BI Publisher report that runs before your FBDI load. The SQL should query:

  • Existing suppliers with normalized Tax IDs matching your import file
  • Name similarity matches using SOUNDEX or fuzzy matching
  • Suppliers with identical addresses but different names

Schedule this report to run 30 minutes before your nightly FBDI job. Configure it to send alerts if potential duplicates are detected, which pauses the load until manual review.

Implementation Approach:

  1. First, clean existing duplicates using the Merge Suppliers process
  2. Implement the enhanced duplicate prevention rules
  3. Add Tax ID normalization to your ETL pipeline
  4. Switch hierarchy loads to HDL format
  5. Deploy the pre-validation report with automated scheduling

This comprehensive approach addresses all four focus areas and should eliminate your duplicate vendor issues while properly maintaining hierarchies. The payment routing failures will resolve once duplicate vendors are prevented from entering the system.

This draft is based on general Oracle Fusion Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

I’ve seen this exact issue before. The Tax ID format inconsistency is your main culprit. FBDI doesn’t automatically normalize Tax IDs before checking for duplicates - you need to handle that in your source data preparation.

For the hierarchy issue, FBDI processes records sequentially and can create orphaned child records if parent vendors aren’t loaded first. You might want to sort your load file by hierarchy level before importing.

timothy_tech 4

Tested this on Oracle Fusion Cloud 23D — enabling ‘Normalize Tax IDs’ with 85% fuzzy matching in Manage Supplier Duplicate Prevention Rules eliminated our FBDI-generated duplicate vendor records immediately.

5

Quick suggestion - implement a pre-validation script that normalizes Tax IDs before your FBDI load. Remove all special characters and padding to create a clean comparison field. This should catch most duplicates at the source.

Also check your duplicate detection rule configuration in Setup and Maintenance. The default rules might not be strict enough for your requirements.

6

We had similar payment routing failures due to duplicate vendors. What helped us was creating a custom validation report that runs before the FBDI load. The report queries existing suppliers and flags potential matches based on normalized Tax ID, name similarity, and address.

For vendor hierarchies, HDL definitely handles parent-child relationships more reliably than FBDI. HDL allows you to define hierarchy structures explicitly in the load file, while FBDI can struggle with referential integrity during bulk loads. The trade-off is that HDL has a steeper learning curve for the template structure.

7

I recommend switching to HDL for vendor hierarchies specifically. The FBDI approach works fine for flat vendor lists, but once you introduce parent-child relationships, HDL’s explicit referencing is much more reliable.

For duplicate detection, you can enhance the out-of-box rules by adding custom attributes to the matching criteria. We added a normalized Tax ID attribute that strips all formatting before comparison.

8

Have you looked at the Supplier Duplicate Prevention rules in the Procurement setup? There’s a configuration path under Setup and Maintenance > Supplier Duplicate Prevention that lets you define matching attributes.

You can configure it to check Tax ID with normalization rules applied automatically. This catches duplicates during creation rather than after the fact.