NETWORK · CLIENT PORTAL
Your client orders from fifteen suppliers a year. Most send PDF invoices and expect to be chased for status. Approvals happen by email and stall the day someone forgets. “Where's my order?” arrives in your CS team's inbox fifty times a week. Claims and disputes live in three-day email threads, then disappear into shared folders. The client comes away thinking your business runs on PDFs.
The TradeOS Client Portal is that portal, fully operator-branded. Nine sections of real surface — orders, production, shipments, invoices, claims, samples, approvals, messages, account. Three state machines (claims · samples · approvals). Stripe Connect rails. Service-layer redaction — your supplier and margin never cross the boundary.
Portal sections
9 · orders, shipments, finance, claims, and 4 more
State machines
Claims, samples, approvals
Multi-operator identity
One login, all your operators, unified view
Cost to client
$0 · unlimited seats
Operator proposes lot 4 quantity 150K → 200K units. Same spec, same ship date. Net change: +$140,000 · within your $200K director-tier ceiling. Raised 11 min ago.
The real Home dashboard — operator-branded chrome, 9-section nav, hero status strip, action prompt for pending approvals, two-column grid with active shipment + invoice center, recent activity feed. Single backend call (GET /api/portal/client/dashboard) returns everything. The dashboard adapts through 4 ClientDashboardMode states as the client's first session unfolds (fresh → mid-production → mid-shipped → active).
THE INBOX THAT NEVER EMPTIES
The work is real: clients want to know where their orders are, want approvals to be fast, want to feel like they're dealing with a serious business. The default tooling — PDF + email + shared folders — costs your CS team days a week and costs your renewal rate something even bigger.
01 · “WHERE'S MY ORDER?” LIVES IN 50 EMAILS A WEEK
The client wants to know if RD-2026-018 has shipped. They email procurement, who emails ops, who opens four sections, retypes the answer back. By the time the email arrives the lot has advanced two stages. Multiply by twenty clients and that's two days a week of CS time spent on status updates the record already has.
02 · APPROVALS STALL IN PDF CHAINS
You send a quote, an order, a counter-proposal. The client says they need to escalate. Three days later you ping them. They forgot. Two days after that the approval arrives by email — but the terms you'd updated in the meantime aren't reflected. The deal moves at the speed of the slowest inbox.
03 · YOU LOOK LIKE A PDF MILL
Your client orders from fifteen suppliers a year. The one with a branded portal — orders, shipments, claims, approvals all in one surface — feels like a different category of business. They get renewed. You get put back out to RFP.
9 SECTIONS · ONE PORTAL
Real CLIENT_NAV.flatLinks from client/src/lib/navConfig.ts. Mobile bottom-nav uses four: Home · Orders · Payments (the /invoices route renamed, because clients think “I'm paying things”) · Messages.
1,710-line adaptive dashboard. Hero status + action prompt + 2-col grid with active shipment (D3 map) and invoice center. Four ClientDashboardMode states for first-session vs ongoing-relationship rendering.
PO acceptance, amendments, line items, lots, shipment linkage. 608-line list + 964-line detail. Approval routing via task engine.
Watch the goods being made — production phases, factory progress, lot tracking. Source identity always anonymized (redacted at service layer).
D3 + topojson map, real-time milestones (booked → loading → departed → arrived), document attachment. Same renderer the homepage uses.
Invoice list + 764-line detail. Pay via Stripe Connect (4 rails). On mobile this renames to Payments in the bottom-nav.
Visibility-tag driven access. CO, BL, packing list, CI, COA, insurance, phytosanitary, QC. Async export (orders/invoices/docs/messages/audit).
Tasks scoped to the client. Auto-spawned by client portal actions on the operator side via auto-tasks.service.ts. Approvals also live here (task_category='approval').
Threaded messaging with the operator. Attached per entity (order, invoice, shipment, claim, sample). 5-category notification prefs.
Relationship-level analytics. Aggregated across operators at Business+ tier (real cross_operator_analytics feature).
CLAIMS & SAMPLES · COMMERCIAL WORKFLOWS
Every B2B relationship has commercial events that aren't orders or invoices — quality issues, short shipments, sample requests, gold-sample sign-off. Most operator software treats these as out-of-band email exchanges. TradeOS treats them as first-class entities with enforced state machines.
CLAIMS · MIGRATION 165 · 6 STATES
Real client_claims table. Six claim types covering the full universe of “we have a problem with the goods” — distinct from invoice disputes (which are about invoice content, handled separately in mig 166).
Branches: escalated · cancelled. Six resolution kinds (replacement_shipment · credit · refund · price_concession · no_action · dispute). Photos and evidence in JSONB. Three severity levels (minor / major / critical). Client raises and accepts proposals; operator investigates and proposes resolutions — distinct write paths in different services.
SAMPLES · MIGRATION 163 · 8 STATES
Real sample_requests table. Five sample types covering the validation cycle from “first thing the factory ships” to “the reference standard both sides retain.”
Decision branches: approved_with_conditions · rejected · cancelled. Photos and annotations from both sides. Gold samples have retain_until dates (typical 2 years). The portal carries the entire workflow — request, photo upload, annotation, decision, retention — without falling back to email.
SCALES WITH YOUR CLIENTS
The same portal serves the corner-store buyer and the Fortune 500 procurement org. The five real client.*_approvals tier features (migration 161) gate progressively richer routing as the operator's tier moves up. The client's procurement process is respected, not imposed.
TIER · STARTER (SMB DEFAULT)
1 approver · no routing
Owner / Buyer
FULL AUTH · ANY AMOUNT
approve
REAL FEATURE KEY
client.single_approver_workflow
EXAMPLE CLIENT
Independent pharmacy chain · 4 locations · $80K/mo spend
TIER · SOLO+ / TEAM+
3 approvers · ladder by dollar value
Team lead
PROCUREMENT TEAM
< $50K
Director
DIRECTOR · PROCUREMENT
$50K — $200K
VP · Supply Chain
VP · SUPPLY CHAIN
> $200K
REAL FEATURE KEYS
client.amount_based_approvals(Solo+) ·client.sequential_multi_step(Business+)
EXAMPLE CLIENT
Regional medical distributor · 14 sites · $4M/mo spend
TIER · BUSINESS+ / ENTERPRISE
Configurable · n-of-m · delegation policies · audit log
Requester
SITE LEAD
submit
Cost-center owner
FINANCE GATE
any
Quality / Compliance
REGULATED · MEDICAL
QA
Security / Vendor Risk
SAML · ENTERPRISE
risk
VP · Supply Chain
FUNCTION HEAD · DELEGATION OK
< $5M
CFO sign-off
EXEC · WITH DELEGATION
> $5M
REAL FEATURE KEYS
client.parallel_approvals · client.delegation_policies · client.category_based_approvals(Business+) ·client.custom_approval_builder(Enterprise)
EXAMPLE CLIENT
Fortune 500 hospital network · 200 sites · $40M/mo spend
DATA ISOLATION · ARCHITECTURAL
A client portal that leaks your supplier or your margin is a portal you don't ship. Radical transparency on status; opaque on origin. Every visible field was deliberately exposed; everything else is invisible before the row leaves the database.
Only their own orders, their own data
A client never sees another of your clients on the platform. Per-connection scope at the service layer; cross-operator unified view (Starter+) aggregates only this client's own data across operators they're connected to.
Never your suppliers or manufacturers
“Production in progress” — not factory name, not country, not lot location. Real redactFor() in server/src/modules/portal-shell/redaction.ts rewrites the row before it leaves the service.
Never your cost, margin, or pricing structure
They see their commercial price. They never see what you paid the factory, your freight cost basis, or what other clients on the same SKU are charged.
Document redaction at the service layer
Even if a document has a supplier reference in metadata — a PDF's XMP block, an Excel header, a watermark — it's rewritten before serving. No “leak via accidentally-shared file” path.
No Settings toggle to misconfigure
There is no admin UI where an operator could flip the wrong switch and expose cost. The boundary is encoded; the only way past it is a deploy-gated code review.
OPERATOR-BRANDED · THEY SEE YOU, NOT TRADEOS
Your clients don't choose vendors based on the back-office software you use — they choose based on how the vendor presents itself. The Client Portal is the operator's primary surface for that presentation. Every visible byte goes out under your brand.
LAYER 01 · YOUR LOGO, YOUR COLORS
AVAILABLE FROM · SOLO TIERUpload a logo, pick a primary brand color, and every artifact the client touches inherits it — portal UI, PDF invoices, signed contracts, email notifications, downloadable manifests. The TradeOS wordmark is restricted to a small footer on the portal; on documents, it's not present at all.
LAYER 02 · CUSTOM DOMAIN
AVAILABLE FROM · ENTERPRISE TIERYour clients never type “edma” or “tradeos” into a browser. Real client.custom_domain feature key at Enterprise tier — full white-label per migration 161. The portal is served from your own DNS, with a certificate provisioned for your domain. The URL bar is part of your brand — and it stays clean from sign-in all the way to a paid invoice.
Operator email sender (DKIM-signed outbound from your domain) is on the roadmap — flagged honestly in §13 below.
ONE CLIENT · MANY OPERATORS · UNIFIED VIEW
A client legal entity connected to multiple operators on TradeOS gets a unified read view via real client.cross_operator_account feature key (Starter+ tier, migration 161) and the /cross-operator/dashboard endpoint in portal-client/services/cross-operator.service.ts.
One user, one login, all their operators in one screen — per-connection isolation preserved. Each operator's data stays scoped to that connection; aggregation only happens at safe summary level (counts, totals, no PII leakage between operators). Cross-operator analytics at Business+ tier.
This is a deliberate deviation from the FAQ many client-portal SaaS products give — “client identity is operator-scoped, no cross-operator views.” TradeOS exposes the unified view because clients actually need it and per-connection isolation in the aggregation layer is the architectural safeguard, not the absence of the surface.
PAYMENTS · STRIPE CONNECT
Real client.direct_payment_rails feature key (Starter+, migration 161). Four Stripe Connect rails — card · ACH · SEPA · BACS. Read-side payment history ships at launch; the INITIATE side ships with the Stripe webhook receiver, currently behind the v1.1 milestone. Both surfaces are flagged below so you know exactly what's wired vs UI-ready.
CARD
Visa, MC, Amex via Stripe. Instant settlement. Best for SMB clients who want speed; not for high-value invoices where the fee matters.
ACH
US bank-to-bank. 2-day settlement. The default for large invoices. Cheapest fee per dollar moved.
SEPA
EU bank-to-bank. 2-day settlement across the SEPA zone. The default for European clients paying European operators.
BACS
UK bank-to-bank. 3-day settlement. The default for UK clients. Replaces Direct Debit for one-time payment flows.
STATUS
READ surface live · INITIATE surface ships with the Stripe webhook receiver (v1.1)
Scheduled and recurring payments at Business+ tier (client.scheduled_payments)
AI · ACROSS CLIENT EVENTS
Every client interaction in the portal is an event the AI stack can act on. The same data-isolation rules apply — Atlas reasons over the client's own scope, never across other clients of yours.
AATLAS · DRAFTING CLIENT REPLIES
The client asks “can we accelerate by 3 days?” Atlas pulls current production %, freight options, pricing impact, and drafts a reply in your voice. You hit send. The record updates automatically.
▶ FWD ATLAS · A. Kohl @ Brevin"Can we accelerate PO 0418 by 3d?"▶ ATLAS · draft reply"Yes — air-freight lot 3 for +$14K (currently 78% production, ETA Jul 18 instead of Jul 21). Confirm by EOD Tuesday and we'll book."→ context · production · freight · margin (private)
BBOT STUDIO · ON CLIENT APPROVALS
You build the bot once. It watches client-approval events: auto-updates the supplier's production plan, drafts the forwarder note, recalculates the invoice schedule, and only escalates to a human when the change crosses a threshold.
▶ BOT client-approval-cascade · v2.4→event ·approve · +50K units→supplier plan ·lot 4 updated→forwarder ·capacity check requested→invoice schedule ·+$140K · INV-019→human ·none required
$ACCOUNTING AI · ON CLIENT PAYMENTS
The client pays $560K via ACH. Accounting AI matches the rail to the invoice, posts it to your ledger, flags any short-pay against a known holdback policy, and surfaces only the cases that need a human eye.
▶ ACCOUNTING AI rail match · v1.8→ ACH · $560,000 · ref MERIDIAN-018→matched ·INV-2026-018 · 100%→ledger ·posted · AR cleared→next ·INV-019 holdback 2.3% · review
COMPARE
Email and PDF is the incumbent — and it wins on familiarity, loses on everything else. Customer Communities and Ariba win on enterprise procurement, lose on operator-branding and margin protection. In-house portals win on flexibility, lose six months later.
| Capability | TradeOS Client Portal | Email + PDF | Salesforce Customer Communities | Ariba Buyer (forced on you) | In-house custom portal |
|---|---|---|---|---|---|
| Operator-branded (your domain, your colors) | ✓ portal.yours.com · Enterprise tier | ✓ your sig | your colors, Salesforce URL | — SAP brand | ✓ |
| Real-time status visibility · same record | ✓ single backend call | — manual | via integrations | async sync | DIY |
| Inline approvals · single tap to custom builder | ✓ 5 tier-gated levels | — PDF + email | ✓ workflow builder | ✓ enterprise only | DIY |
| Stripe Connect payment rails (card · ACH · SEPA · BACS) | ✓ all 4 · transparent fees | — wire only | via 3rd-party | ACH · wire | — rare |
| Cross-operator unified view (one login, all your operators) | ✓ Starter+ feature | — N/A | — per-org silo | — per-org silo | — DIY |
| Cross-tenant data isolation enforced architecturally | ✓ redactFor() in API | — leaks by accident | org-level | tenant-level | — DIY |
| Claims + Samples workflows (state machines) | ✓ 6 + 8 states · live | — ad-hoc email | cases module | — out-of-band | — DIY |
| SAML SSO at Enterprise | ✓ client.saml_sso | — | ✓ SF Identity | ✓ | DIY |
| Free seats for clients (operator pays for TradeOS) | ✓ unlimited at tier | ✓ email is free | — per community user | — per-seat | ✓ in-house |
| Native AI integration (Atlas · Bots · Accounting) | ✓ scoped per client | — bring your own | Einstein add-on | Joule add-on | — |
Email is the actual incumbent — and it wins on familiarity for a reason. Clients are fluent in PDF. The Client Portal isn't trying to replace email by being more impressive; it's trying to replace it by being easier than email for the things email is bad at: status visibility, approval routing, payment, claims, samples, document attachment to the right PO, and not making the operator look like a vendor running on Excel.
TIER GATING · 19 FEATURE KEYS
Real tier_features registry (migration 161) defines nineteen client-portal feature gates. Clients never see a paywall; the connecting operator's tier decides what's available in your workspace for that operator. Roadmap tags mark features whose tier_feature key is registered but whose UI/engine implementation is post-launch.
ON THE ROADMAP
v1 ships nine sections, three state machines, four Stripe Connect payment rails (READ side live), multi-tenant identity with cross-operator unified view, service-layer redaction, PWA install, onboarding overlay + tier-aware checklist, auto-tasks, data export, and tier gating across nineteen feature keys. The capabilities below are flagged honestly — their tier_feature keys exist but their UI / engine / wire-up lands post-launch.
01
READ surface (payment history) is live. The INITIATE side — POST /invoices/:id/pay — is stubbed pending the Stripe webhook receiver that writes payment rows. Per payments.service.ts: “Stubbed exactly like createSetupIntent. Throws ValidationError with documented next steps.”
02
Order confirmations, approval requests, shipment alerts, invoice notices — delivered from [email protected], not from TradeOS infrastructure. SPF, DKIM, DMARC configured on your DNS. Not implemented yet; Enterprise tier when built.
03
SAML SSO is live at Enterprise tier (client.saml_sso). OIDC and SCIM auto-provisioning land next — same Enterprise gate. SCIM de-provisions when the client's HR system offboards a user, so portal access tracks the client's source of truth.
04
Real client.order_templates feature key at Business+ (mig 161, flagged “UI post-launch”). The schema is ready; the saved-template picker + one-click reorder flow ships post-launch.
05
client.custom_approval_builder at Enterprise tier. The runtime engine is in place (parallel, sequential, n-of-m, delegation, category routing all work); the visual builder UI for non-technical operators ships post-launch. Operators on Enterprise can request hand-built workflows from us in the meantime.
06
client.edi_integration at Enterprise tier (mig 161). For enterprise clients on EDI, the order/shipment/invoice flow lands directly via X12 / EDIFACT instead of the portal UI. Schema reserved; integration adapters ship per-customer as Enterprise contracts close.
07
The four Stripe Connect rails (card / ACH / SEPA / BACS) cover the digital-rail universe. Wire and LC are out-of-band rails the operator can still record manually against an invoice today. Native portal flows for wire confirmations and LC presentation tracking ship as the use cases concentrate.
08
PWA is the v1 client mobile surface (manifest + service worker + InstallNudge — already shipping). Native apps with biometric auth, native camera APIs, and push notifications land post-launch.
FAQ
Honest answers to the questions distributors, importers and trading-company owners hit us with on the demo call.
Yes — but it's branded as your system. They see your logo, your colors, and at Enterprise tier a custom domain (portal.yourcompany.com with your own SSL cert). Most clients prefer this to chasing email PDFs; the operators who switched report procurement teams asking for the portal first, not vice versa.
Book a 30-minute demo. We'll spin up a sandboxed Client Portal with your logo, your brand color, your custom domain on a staging subdomain, a fictional order, and a fictional VP of procurement. You walk through it on a real desktop and a real phone. If they wouldn't prefer it to a PDF chain, we won't ask you to buy it.