Platform
Your distributors do not need a login to your system
The RevUpra Partner Portal is a separate application with its own database and its own users. A distributor signs in once and works with every manufacturer they buy from — and nothing they do there reaches your instance except through an interface you registered.
The financial problem
Everything a partner cannot check before sending, you pay for finding.
- Claims are argued for weeks because the first time anyone tests them against your rules is after they have landed.
- Sell-through and stock arrive in the partner’s own part numbers, so the data your accrual depends on is a match rate rather than a fact.
- A partner who cannot see why a line was cut opens a dispute instead, and answering it costs a person on each side.
- Remittance arrives as a payment nobody can tie back to a claim, which produces the next query.
The technical problem
Giving a trading partner an account in the system that holds your book is the wrong answer.
- The portal is a separate application with its own database and its own users. It never reads or writes a manufacturer’s database.
- Every exchange is a registered REST or flat-file interface on both sides — no shared schema, and nothing implicit.
- Each connection is isolated at the database row level and carries its own scoped API key, granted and revoked by you.
- Outbound messages leave through an outbox that retries until it is delivered and acknowledged, and a resend is idempotent — so a partner retrying cannot double-post.
What the distributor does
Write it, check it, follow it, reconcile it
One sign-in covers every manufacturer they buy from. They pick a manufacturer and see all of that manufacturer’s divisions together.
Claims checked before they are sent
A claim is written in the portal and tested against your own validation rules before it leaves. The findings are the partner’s to fix rather than yours to explain.
Every claim, followed through
Validation, settlement and payment as one visible track, so “where is my claim” is a page rather than an email.
POS and inventory uploads
Sell-through and stock submitted in the partner’s own part numbers, with the review of each batch visible while it is worked.
Their identifiers, your masters
The partner sees how you map their parts and entities to yours, and proposes a correction where the mapping is wrong.
What was actually paid
Settlement per claim, carrying the manufacturer’s own credit or claim reference, so the money can be matched when it arrives.
Line-by-line disposition
Claimed against settled for each line, and how it was decided — which removes a dispute rather than routing it.
What you publish
You decide who is connected, and what they see
A grant is an act of administration, not an integration project. New tenants are connected to the portal when they are created.
Authorisations & special pricing
Debit authorisations and the pricing behind them published to the partners they belong to, as they are agreed.
The manufacturer profile
Who you are, who to contact and how you work — maintained once and read by every partner you have granted.
Acknowledgement requests
Ask a partner to confirm they have received and accepted something, and hold their answer against the record.
Remittance
Sent once finance has confirmed the settlement, so what the partner reads matches what the bank is about to do.
Granted from the Integration Hub
You grant a distributor and you revoke them, in one place. Each grant issues its own credential, bound to that partner.
Access is managed per person
One person can hold several distributors, and a distributor can have several people. Access follows the person, so leavers are handled properly.
Benchmarks
What partner self-service should be worth
| Metric | Typical today | Target |
|---|---|---|
| Claim lines checked before the partner sends them | None — findings arrive after receipt | 100%, against your own rules |
| Partner POS matched to your master data | 82 – 92% | >99.5% |
| Logins a partner needs to your systems | One per manufacturer | None — a separate application |
| Claim status the partner can see unaided | On request, by email | Line by line, with the settlement reference |
| Outbound messages confirmed delivered | Assumed | Acknowledged, or retried until they are |
| Duplicate postings from a partner resend | Found at reconciliation | 0 — resends are idempotent |
Bring the claim your partner is still arguing about.
The most useful first conversation is usually one real claim: what your own rules would have said before it was sent, which lines were cut and why, and what the distributor would have seen at each step.