Consolidated Supplier Onboarding Report

Business context

The client is a corporate finance company that processes supplier payments on behalf of many clients, and each of those clients has a large supplier base. A supplier must be onboarded correctly before it can be paid. Missing, outdated or incorrect supplier information is a risk: it delays onboarding, leads to rejected applications and, where banking details are concerned, opens the door to payment fraud.

Challenge

Supplier records were held across at least eight finance systems. The finance team needed a fool-proof, automated way to see, for every client:

• which suppliers had been onboarded, which had been rejected, and why;
• whether each supplier’s required information had been filled in correctly, according to the finance team’s onboarding requirements;
• whether the supplier’s banking details had been verified — and verified by a different person from the one who completed the onboarding, so that no single person could both capture and approve banking details;
• each supplier’s B-BBEE classification and registration, in an easy view across all of the systems.

My contribution

• Consolidated supplier onboarding data from 8+ finance systems into one report, broken down by system and by client.
• Defined field-level checks for each required supplier field, based on the finance team’s onboarding requirements.
• Built onboarding status tracking — onboarded, in progress or rejected — with the reason for each rejection.
• Added a banking-verification control that shows whether banking details were verified, and flags any supplier where the verifier is the same person who completed the onboarding.
• Built a separate B-BBEE view of classifications and registrations.
• Restructured the underlying queries and measured server/query time before and after.

Investigation and methodology

The work started from the finance team’s own onboarding requirements: for each required field, what counts as filled in correctly. Each requirement became a check that runs for every supplier, in every system, for every client.

There is no matching between systems. Each supplier record is checked against the requirements where it lives, so a missing or incorrect value points straight to the system and client where it has to be fixed.

Solution design and implementation

The report serves two purposes.

1. Onboarding control. Onboarding status and rejection reasons, missing or incorrect field values by system and client, and the banking-verification check with segregation of duties. The finance team can see exactly what to investigate and fix, then continue with their processes.
2. B-BBEE overview. Supplier B-BBEE classifications and registration status across all of the systems in one place. This view is used by a separate team, which investigates it independently; it is not matched against anything.

Results and business value

• One view instead of eight: onboarding status, rejection reasons and data issues for every client across 8+ finance systems in a single report.
• Fixable data quality: missing field values are identified per system and client, so the team knows where to fix them.
• Fraud control: banking details must be verified, and verified independently of the person who completed the onboarding; exceptions are flagged.
• Query side: measured server/query aggregate reduced from approximately 390 seconds to approximately 89 seconds, about 77%.

Technical details

• Required-field checks: each supplier field tested for presence and validity against the onboarding requirements, per system and per client.
• Segregation of duties: the banking check compares the user who completed the onboarding with the user who verified the banking details and flags any record where they are the same.
• Rejections: rejection reasons captured as categories, so recurring causes can be addressed at source.
• Timing scope: aggregate of server/query execution for the reporting workload; visual rendering and refresh orchestration excluded. (390 − 89) ÷ 390 ≈ 0.772.

Lessons, constraints and improvement opportunities

• A check is only useful when it says where the problem is: “missing in this system, for this client” is something a person can act on.
• Controls such as segregation of duties are easiest to sustain when the report makes every exception visible.
• Be precise about what a performance number measures; query time and refresh time are different claims.