Skip to content
Vendor Management Platform
Contact
EnterpriseEnterprise web appIn production

Vendor Management Platform

Supplier onboarding, compliance and invoicing on top of SAP.

Start a similar projectSee the architecture
Client
Mid-size manufacturer (NDA)
Role
Lead product engineer
Year
2025
Industry
Manufacturing
Built withNext.jsTypeScriptNode.jsPostgreSQLSAP ODataOpenAIRedisDocker

Problem

Supplier data lived in inboxes, not in SAP

Onboarding a supplier meant a chain of emails: a registration form as an Excel attachment, bank details in a PDF, certificates sent whenever someone remembered. Procurement copied every field into SAP by hand, and nobody owned the question of when a certificate would expire.

BeforeEmail, sheets and chat
  • Fwd: Supplier registration form (v3).xlsxProcurement, via email
  • Re: Re: Updated bank details, please confirmSupplier, via email
  • Is this ISO certificate still valid?Compliance, via chat
  • Vendor master request: still pending in SAPProcurement, via SAP GUI
Representative examples, reconstructed from discovery interviews.

  • Onboarding by email

    Forms, bank letters and certificates arrived as attachments across several inboxes, with no single view of what was still missing.

  • Re-keying into SAP

    Procurement typed each vendor record into SAP, so typos in bank details and tax IDs travelled all the way to payment runs.

  • Silent expiries

    Quality and insurance certificates lapsed unnoticed until an audit or a blocked delivery surfaced them.

  • Late invoice mismatches

    Invoices that didn't match purchase orders were found at month-end reconciliation, long after the goods had arrived.

Research

Mapping the real process before drawing a screen

Discovery ran alongside procurement, finance and compliance. The goal was to find where supplier data entered the business, who touched it on the way, and where SAP had to stay the only source of truth.

  • Stakeholder interviews

    Procurement managers, finance approvers and compliance officers each walked through their most recent supplier cases.

  • Process mapping

    Traced a supplier from first contact to first paid invoice, marking every hand-off, copy-paste and waiting period.

  • Vendor master audit

    Reviewed the SAP vendor master fields, number ranges and mandatory checks the portal would have to respect.

  • Document sampling

    Collected redacted certificates and invoices to test what extraction could read reliably, and what it couldn't.

What we learned

  • SAP had to remain the system of record. The portal could propose changes, but never bypass SAP's own validation.
  • Most of the delay came from waiting on missing documents, not from approvals.
  • Suppliers were happy to self-serve as long as the checklist told them exactly what was missing.
  • Compliance needed expiry dates as data they could act on, not as text inside a PDF.

User journey

From first invite to a compliant, payable supplier

A composite persona built from the interviews, following one supplier through onboarding.

BeforeWith the product

  1. 1

    Invite the supplier

    Before: Emailed a spreadsheet form and waited for it to come back complete.

    Now: Sends a portal invite; the supplier gets a checklist tailored to their category.

  2. 2

    Collect documents

    Before: Chased certificates and bank letters across separate threads.

    Now: Uploads are checked on arrival and anything missing stays visible to the supplier.

  3. 3

    Verify the data

    Before: Retyped fields from PDFs and compared them by eye.

    Now: Fields are pre-filled with a confidence level; only uncertain ones need her.

  4. 4

    Approve and create in SAP

    Before: Forwarded to finance for approval, then keyed the vendor into SAP.

    Now: Role-based approval in the portal, then the vendor is created in SAP automatically.

  5. 5

    Stay compliant

    Before: Found out about expired certificates during audits.

    Now: Expiry dates drive reminders to the supplier before documents lapse.

Solution

A supplier portal with SAP as the source of truth

Suppliers onboard themselves through a guided checklist. Procurement works from one console where every supplier, document and approval is visible. The portal writes to SAP through OData with the same validation SAP applies, and reads changes back so both sides always agree.

  • Guided onboarding

    A checklist per supplier category that only asks for what applies, with inline validation of tax IDs and bank details.

  • Two-way SAP sync

    Approved suppliers are created in SAP, and edits made in SAP flow back, so the portal never drifts.

  • Document extraction

    Certificates and invoices are read on upload, pre-filling fields and expiry dates for review.

  • Approvals and audit

    Configurable approval steps, role-based access and an audit log entry for every change to a supplier.

How the work flows

Switch between the old process and the one the product runs.

  1. 1

    Portal invite

    The supplier gets a checklist tailored to their category.

    AutomatedOwner: Portal
  2. 2

    Supplier self-serves

    Uploads are validated on arrival; gaps stay on the checklist.

    Person, in productOwner: Supplier
  3. 3

    AI extraction

    Fields and expiry dates are read with a confidence level.

    AutomatedOwner: Extraction worker
  4. 4

    Review flagged fields

    Only low-confidence or rule-breaking fields need a person.

    Person, in productOwner: Procurement
  5. 5

    Approve in one place

    Finance approves with the full record and history in view.

    Person, in productOwner: Finance
  6. 6

    Create in SAP

    Posted through OData; the SAP vendor number is written back.

    AutomatedOwner: Sync worker
  7. 7

    Expiry reminders

    Suppliers are reminded before a certificate lapses.

    AutomatedOwner: Scheduler
People step in only to review flagged fields and approve. Everything else runs inside the product.

Architecture

Built around SAP, not beside it

A Next.js front end talks to a Node.js API that owns every business rule. Slow or unreliable work (extraction, SAP writes, reminders) runs on Redis-backed queues, so the interface stays fast and failures can be retried. PostgreSQL holds portal state and the audit log; SAP S/4HANA stays the system of record for vendor master data.

  • Interface
  • Service
  • AI
  • Data and queues
  • External system

Interfaces

Application

Workers and storage

External systems

Portal API

Node.jsService

Owns the business rules: onboarding checklists, approval routing, permissions and the audit log. Every write goes through it.

Why it's built this way

One API for both front ends, so each rule is enforced once rather than duplicated in two interfaces.

Connections

UI

Two audiences, one design language

Suppliers get a calm, guided flow that works on a phone. Procurement gets a dense, keyboard-friendly console built on saved views. Both share the same components, so a status means the same thing everywhere.

The supplier list procurement works from, with saved views for category, status and expiring documents.
Approval routing configured as data, by supplier category and risk, next to the supplier's own checklist on mobile.

  • Status before detail

    Every list leads with what's blocking a supplier: a missing document, a pending approval or a sync error.

  • Two audiences, two densities

    The supplier portal is guided and spacious; the console is compact and built for working through lists.

  • Show the source

    Any AI-filled field links to the highlighted region of the document it came from.

Development

Built to be changed safely

Development ran in short cycles with a demo at the end of each, against an SAP quality system rather than production. The priority was making SAP integration boring: typed, tested and observable.

  • Typed contracts end to end

    Shared TypeScript types between the API and both front ends; OData payloads are validated at the boundary before they reach business logic.

  • SAP sandbox first

    Every SAP write was built against the client's quality system with recorded responses, so integration tests run without touching production.

  • Reviewed migrations

    Schema changes ship as reviewed migrations, and seeded supplier scenarios make QA and demos repeatable.

  • Containerised delivery

    Docker images per service, promoted from staging to production, with environment-specific SAP endpoints injected at deploy time.

Stack

Frontend
Next.jsTypeScript
Backend
Node.jsRedis
Data
PostgreSQL
AI
OpenAI
Integration
SAP OData
Delivery
Docker

AI

AI pre-fills, people decide

The extraction worker reads certificates and invoices with a model that must answer in a fixed JSON schema. Every field comes back with a confidence level. Anything below the threshold, or anything that breaks a business rule, is routed to a person instead of being saved silently.

Certificate extraction

Sample data

Globex Certification Services

Certificate of registration

  • This certifies that the quality management system of
  • Northwind Components Ltd
  • has been assessed and found to conform to
  • ISO 9001:2015
  • Certificate number QMS-48213
  • Valid until 03/04/2027
  • Scope: machining and assembly of precision parts

Extracted fields

  • Supplier
  • Standard
  • Certificate number
  • Expiry date
  • Scope
Waiting to read the documentA supplier uploads a quality certificate. The worker reads it, scores each field and routes the uncertain one to review.
  1. 1

    Classify the upload

    Detects whether a file is a certificate, bank letter or invoice, and which checklist item it satisfies.

  2. 2

    Extract to a schema

    The model returns typed fields, such as certificate number, issuer and expiry date, validated against a JSON schema.

  3. 3

    Score confidence

    Each field is scored from model signals plus rule checks like date formats and tax ID checksums.

  4. 4

    Route exceptions

    Low-confidence or conflicting fields go to the review queue with the source region highlighted.

Guardrails

  • No field reaches SAP without passing validation and, where the rules require it, a human approval.
  • Only the pages needed for extraction are sent to the model, never other suppliers' data.
  • Every AI suggestion is logged with the reviewer's decision, so accuracy can be checked over time.

Integration

Four systems, each with a clear owner

Each integration has one job and one direction of truth. SAP owns vendor master data, Azure AD owns identity, and the portal owns the onboarding process in between.

  • SAP S/4HANA

    OData, Business Partner API

    Creates and updates suppliers as business partners, and polls for changes made in SAP so both sides stay reconciled.

    Two-way

  • Azure AD

    OpenID Connect

    Single sign-on for internal users; group membership maps to procurement, finance and compliance roles.

    Inbound

  • SendGrid

    REST API

    Invites, reminders and approval requests from versioned templates, sent from background jobs.

    Outbound

  • S3 document storage

    Signed URLs

    Encrypted document storage with direct browser uploads and short-lived download links.

    Two-way

Performance

Fast where people wait, patient where systems do

The console has to feel instant while SAP and the model take their time. The approach: keep slow work off the request path, and make list views cheap to query.

  • Server-side pagination

    Supplier and document lists page, sort and filter in PostgreSQL, so the console stays quick as the supplier base grows.

  • Indexes that match the views

    Composite indexes on what procurement actually filters by (status, category, expiry date), checked with query plans.

  • Cached SAP lookups

    Reference data such as company codes and payment terms is cached in Redis with explicit invalidation, instead of calling SAP on every page view.

  • Background jobs

    Extraction, SAP writes and emails run on queues with retries and backoff, so no request waits on SAP or the model.

  • Direct-to-storage uploads

    Documents go straight to S3 through signed URLs, keeping large files off the API servers.

  • Lean bundles

    Server components for read-heavy pages; heavy widgets such as the document viewer load only when opened.

Outcome

Suppliers onboard themselves, and SAP stays clean

Procurement stopped acting as a relay between suppliers and SAP. Suppliers see exactly what's missing and fix it themselves, vendor data is entered once and synced, and compliance works from dates rather than PDFs. The audit log means any change to a supplier can be traced back to a person or a job.

What's next

Next on the roadmap: supplier scorecards built from delivery and quality data that already lives in SAP.

What changed

  • Suppliers onboard themselves instead of emailing forms back and forth
  • Vendor data is entered once and synced to SAP, not re-keyed
  • Expiring compliance documents are flagged before they lapse

Outcomes are described qualitatively. Client figures stay with the client.

Have a similar project?

Whether it's a workflow that still runs on email and spreadsheets or a system you need to integrate with, tell me what you're building. I reply within one business day with questions and a suggested first step.

Start a similar project