# Supplier onboarding exceptions system map | SourceX

Canonical: https://refer.sourcex.si/guides/supplier-onboarding-exceptions-records-across-systems
Last updated: 2026-10-18

Reconstructing a supplier onboarding exception across systems needs one identifier that the supplier portal, the screening tool and the document trail all carry, usually the portal's request ID, and then the supplier number once the ERP issues one. The screening case ID and the TIN check date are secondary keys. Where screening lives in a separate GRC tool that stores only a name and a date, the chain has to be rebuilt by matching names, which is the very problem these exceptions are about.

This system map is part of the [supplier onboarding exceptions guide](/guides/workflow-supplier-onboarding-exceptions). It shows where each record sits, which key joins it to the next, who owns it, and what one fully joined case looks like.

## Four systems, one supplier file

An onboarding exception rarely lives in one place. A typical mid-size company spreads it across:

- **Supplier portal:** the request, the duplicate check, document requests and often the acceptance note.
- **GRC or screening tool:** sanctions and watchlist screening, hits and dispositions.
- **Tax or AP tool:** W-9 intake and TIN check results.
- **ERP vendor master:** the supplier number, bank details, affiliate links and later payment history.

Each system was bought by a different team for a different reason. None was designed to tell the story of one exception end to end, so the joins between them decide whether the story can be told at all.

## The system map

| System | Record | Linking key | Joins to | Owner | Typical gap |
|---|---|---|---|---|---|
| Supplier portal | Supplier request | Request ID | Duplicate check, supplier number | Supplier operations | Request purged after approval |
| Supplier portal | Duplicate-check result | Request ID plus matched supplier ID | Existing vendor record | Portal administrator | Inactive suppliers not checked |
| Portal or email | Missing-document request | Request ID | Documents received | Supplier operations | Sent from personal mailboxes |
| GRC or screening tool | Screening record | Screening case ID, entity name | Request ID or supplier number | Compliance | Linked by name only |
| GRC or screening tool | Screening disposition | Screening case ID | Acceptance note | Compliance | Reason missing or free text |
| Tax or AP tool | TIN check result | Supplier number, check date | Vendor master record | AP or tax | Stored as a checkbox, not a code |
| ERP vendor master | Bank verification note | Supplier number | Payment history | AP | Note kept outside the ERP |
| Portal or ERP | Acceptance note | Request ID and supplier number | Payment history | Supplier operations head | Left in the old portal |

The request ID carries the case until a supplier number exists; after that, the supplier number carries it. The screening tool is where the chain most often snaps, because many screening tools are fed a name, not a request ID.

## One fully joined case (Illustrative)

Every identifier below is invented. It shows what a joined case looks like when each system carries the key it should.

| Step | System | Key seen | Key handed on |
|---|---|---|---|
| Request created | Supplier portal | REQ-20417 | REQ-20417 |
| Duplicate flag | Supplier portal | REQ-20417 matched to V-41022 | REQ-20417 |
| Documents requested and received | Portal | REQ-20417 | REQ-20417 |
| Screening run and cleared | GRC tool | SCR-7731 citing REQ-20417 | SCR-7731 |
| Supplier number issued | ERP vendor master | V-88310 from REQ-20417 | V-88310 |
| TIN check, code 0 | Tax tool | V-88310 | V-88310 |
| Acceptance, affiliate link to V-41022 | ERP | V-88310 and REQ-20417 | V-88310 |
| First invoices paid | ERP | V-88310 | None needed |

The test is simple: starting from the last payment, can someone walk back to the original request without guessing? Here they can, because the screening record cites the request ID and the acceptance note cites both keys. Change one detail, a screening record holding only the supplier's name, and the walk back requires a name match at exactly the point where two names were nearly identical. The [worked exception case](/guides/supplier-onboarding-exceptions-exception-examples) walks through the decisions behind a case like this.

## Where joins fail silently

Two failures deserve a direct question to the portal administrator.

**Records the duplicate check never saw.** SAP's Ariba documentation notes that no duplicate checks are performed against deactivated suppliers, and that custom checks do not match against data that came in through data import, ERP integration or other questionnaires. A company that bulk-loaded suppliers or deactivated old ones may have onboarding exceptions its portal never flagged. Those often surface later in AP instead, as in [purchase order mismatch resolution](/guides/workflow-purchase-order-mismatch-resolution). Other portals behave differently, so treat this as a question, not an assumption.

**Screening keyed by name.** OFAC's Sanctions List Search applies fuzzy logic to the name field only, and anything below a score of 100 is a potential match that needs review. If the company's tool stores the hit against a name rather than a case or request ID, the disposition can still exist and still be hard to join.

A smaller one: TIN results. IRS TIN Matching returns codes such as 0 (match) and 3 (no match). A record that keeps the code joins cleanly; a ticked box that says "verified" tells a reader much less.

## A reconstruction count to request

Ask supplier operations to pick ten onboarding cases from two or more years ago that were paused for any reason, and report three counts: how many trace from request to acceptance by ID, how many need a name match somewhere, and how many have no recorded reason for the decision. Counts only, no files. SourceX does not publish a target figure; the counts simply tell both sides which years of history join cleanly. The [CFO client onboarding questionnaire](/resources/cfo-client-onboarding-questionnaire) shows a similar metadata-only style of asking, and [procurement and vendor workflows](/data-types/procurement-and-vendor-workflows) covers the wider purchasing record set. AP-side invoice exports are discussed in [Bill.com invoice history](/systems/bill-com-export-invoice-history).

## Qualification and what stays unknown

The introduced company needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English.

Unknown until SourceX reviews it: whether screening and tax records can be included, how supplier identities would be de-identified, which years a buyer would want, and whether an offer follows. The [onboarding referral brief template](/resources/supplier-onboarding-exceptions-referral-brief-template) has a line for the reconstruction count.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If a client's portal, screening tool and vendor master share a request ID or supplier number for most paused cases, [register as a partner](/register), check the company against [who qualifies](/who-qualifies) and read the [program terms](/terms) before you introduce the supplier operations head.

## Sources

- https://help.sap.com/docs/ARIBA_SOURCING/f081c6c38fb7466a84d746a7998bfe0e/d586f15765bb4288bc0794e82187a59e.html
- https://ofac.treasury.gov/faqs/249
- https://www.irs.gov/tax-professionals/taxpayer-identification-number-tin-matching
- https://refer.sourcex.si/terms