What Is a Shared Receivables Record? Structured B2B Invoice Evidence Exchange Under the TradePact Protocol

Learn what a shared receivables record is under TradePact Protocol v1.0, how structured B2B invoice evidence exchange works, and how the 5-field schema protects privacy.

A shared receivables record is a neutral, cross-party status projection and audit reference for a registered commercial invoice—anchored by a unique TradePactID—that allows both the supplier and the paying party to verify post-issuance status (Paid, Unpaid, or Unknown), timestamped communication history, and supporting settlement evidence under one common standard (TradePact Protocol v1.0, effective 1 January 2026, operated by ChaseFlow Pte Ltd, UEN 202542183C, in Singapore). Unlike internal single-company accounts receivable (AR) software that locks invoice records inside one vendor's enterprise resource planning (ERP) silo, or credit bureaus that rely on negative post-default reporting, the public record on tradepact.network publishes a strict five-field summary without exposing party names, contact details, or invoice amounts.

This guide is written for commercial finance directors, accounts payable (AP) and accounts receivable (AR) teams, and prospective network participants in Singapore and international trade corridors who want to understand how a shared B2B payment resolution standard works alongside existing e-invoicing and accounting systems.

Key Takeaways (TL;DR)

Cross-party neutrality vs. internal silos: Internal AR tools only reflect one company's private ledger. A shared receivables record under TradePact Protocol v1.0 provides a single, neutral reference (TradePactID) that both commercial counterparties can verify independently.
Bridging the post-issuance gap: Pre-issuance e-invoicing standards (such as XML or Peppol) standardise document delivery at billing, whereas structured B2B invoice evidence exchange governs what happens after issuance—recording delivery confirmation, dispute flags, and settlement status across stages.
Three-layer network architecture: TradePact Network separates the engagement brand a party interacts with (Participants, such as InvoiceMediator and PaymentMediator) from the central execution rail (Infrastructure, operated by ChaseFlow) and behavioural reporting (Intelligence, operated by Late Payer Index).
Five-field closed public schema with anti-enumeration safeguards: Looking up a TradePactID (for example, 20260813000001A) on tradepact.network returns only the TradePactID, status (Paid, Unpaid, or Unknown), masked invoice number, invoice date, and managing participant. Record pages carry noindex and no-store headers and never disclose counterparty identities or S$ / SGD amounts.
Strictly non-custodial settlement: Network participants and the protocol infrastructure never hold, process, or take custody of funds; all invoice payments settle directly between the paying party and the supplier.

What is a shared receivables record?

A shared receivables record is a protocol-governed, cross-party commercial invoice record identified by a unique TradePactID that tracks an invoice from issuance through resolution on shared infrastructure while projecting a privacy-preserving verification summary at tradepact.network.

In standard B2B trade, an invoice creates two disconnected internal records: a receivable entry in the supplier's accounting software and a payable entry in the buyer's ERP system. Once the invoice is issued, follow-up notices, delivery receipts, and payment confirmations typically scatter across bilateral email threads. When personnel change or an invoice is queried, neither side holds a single, mutually verifiable log of what was communicated and when.

Under TradePact Protocol v1.0 (effective 1 January 2026 and operated in Singapore by ChaseFlow Pte Ltd, UEN 202542183C), every registered invoice is assigned a TradePactID (formatted as 20260813000001A). This identifier links the invoice to a centralised evidence log on the network rail while projecting a read-only, five-field status summary on tradepact.network.

That design separates a shared receivables record from two legacy categories:

Internal single-company AR software and shared-services ERPs: Corporate AR automation platforms and internal shared-services centres centralise collection workflows for one enterprise group. However, their records remain private to the seller. A buyer receiving an automated reminder cannot independently verify the record's network status or audit trail on a neutral register.
Credit bureaus and commercial rating agencies: Traditional credit bureaus aggregate historical default data or publish credit scores after a commercial relationship has broken down. Under the TradePact Protocol, no participant operates as a credit bureau, debt collector, debt purchaser, or legal enforcement agency. Engagement begins at invoice issuance to preserve commercial trust rather than penalise a counterparty.

How does post-issuance invoice evidence exchange differ from pre-issuance e-invoicing?

Structured B2B invoice evidence exchange governs the post-issuance lifecycle of a commercial invoice—recording reminders, delivery verification, dispute positions, repayment plans, and settlement status—whereas pre-issuance e-invoicing frameworks such as XML and Peppol only standardise how the initial billing document is formatted and transmitted between accounting systems.

When a Singapore supplier transmits an invoice over Peppol or exports a PDF from its ERP—say, for a S$25,000 commercial supply contract issued on 15 August 2026—the e-invoicing network confirms that the structured billing data reached the buyer's receiving access point. Once that transmission completes, the pre-issuance standard's job ends.

Everything that determines whether and when that S$25,000 invoice is settled happens after issuance:

Proportional post-issuance engagement (Principle 1 — Communication): How the paying party is contacted from invoice issuance onward, how the engaging participant discloses its role in every interaction, and how follow-up remains proportionate to the stage of the invoice (tradepact.net/protocol).
Centralised interaction logging (Principle 3 — Evidence): Recording every notice sent, the recipient, the communication channel, and the exact timestamp on central network infrastructure.
Structured dispute capture (Principle 2 — Resolution): Capturing a paying party's specific query or dispute reason on a participant portal (pay.<domain>) and surfacing it directly to the creditor for a decision rather than letting it stall in an individual inbox.
Cross-participant handoffs (Principle 6 — Interoperability): Carrying the full, auditable interaction history forward when an invoice moves between engagement stages or network participants.

By combining pre-issuance e-invoicing with a post-issuance shared B2B payment resolution standard, finance teams eliminate the visibility gap between the day an invoice is delivered and the day the bank reconciliation clears.

How does structured B2B invoice evidence exchange work across the three-layer TradePact architecture?

Structured B2B invoice evidence exchange operates across a three-layer architecture under TradePact Protocol v1.0: Infrastructure (the central execution rail operated by ChaseFlow), Participants (distinct engagement brands such as InvoiceMediator and PaymentMediator), and Intelligence (behavioural reporting operated by Late Payer Index).

Separating the engagement brand from the underlying execution rail ensures that every party dealing with any network participant encounters the exact same protocol rules, evidence standards, and verification path (tradepact.net/protocol):

1. Infrastructure Layer (Operated by ChaseFlow)

All communication, evidence logging, resolution routing, and record-keeping across the network run on central infrastructure operated by ChaseFlow Pte Ltd. Network participants do not self-host standalone software, hold separate databases, or process engagement data independently. Centralising the rail guarantees that timestamps, delivery records, and creditor decisions are recorded to a single audit standard.

2. Participant Layer (Neutral Engagement Brands)

Participants are the distinct engagement brands that commercial parties interact with—governing the domain an email arrives from and the dedicated portal (pay.<domain>) where an invoice is reviewed, queried, or coordinated. Each participant corresponds to a specific mode or stage of engagement:

InvoiceMediator (invoicemediator.com): A neutral engagement participant supporting structured communication and early issue resolution between suppliers and paying parties.
PaymentMediator (paymentmediator.com): A repayment coordination participant focused on structured payment schedules and resolution plans across involved parties.

Under the protocol's admission criteria, every participant must use an engagement brand separate from any supplier's primary product brand, display the TradePact Network mark on every party-facing touchpoint, route all activity exclusively through network infrastructure, and hold zero financial interest in invoice outcomes (tradepact.net/protocol).

3. Intelligence Layer (Operated by Late Payer Index)

Late Payer Index (latepayerindex.com) derives permissioned payment behaviour reporting from resolution outcomes across the network. Where a client elects not to contribute resolution data to network intelligence, that election is honoured across every participant under the protocol's Behavioural Intelligence commitment. Any request to dispute an invoice or review or correct a behavioural record is handled under the published process at latepayerindex.com (tradepact.net/protocol).

How Evidence Travels With the TradePactID

From the moment an invoice is registered on the network, every interaction—what was sent, to whom, via which channel, and when—is tied to its TradePactID. When a paying party responds on a participant portal to confirm delivery milestones, raise a billing discrepancy, or propose a settlement schedule, that position is logged centrally and put to the creditor. If the invoice moves from initial neutral follow-up (such as InvoiceMediator) to structured repayment coordination (such as PaymentMediator), the portable evidence record moves seamlessly without requiring either counterparty to re-upload documents or reconstruct past emails.

What is the 5-field closed public schema on tradepact.network (and how does it protect privacy)?

The public status lookup at tradepact.network enforces a five-field closed public record schema—returning only the TradePactID, current status (Paid, Unpaid, or Unknown), a masked invoice number, the invoice date, and the managing participant—while excluding all counterparty names, contact details, and invoice amounts.

Commercial finance teams rightly demand strict confidentiality around supplier relationships and invoice values. The public projection on tradepact.network is engineered so that a recipient holding a TradePactID printed on invoice correspondence can confirm the communication is genuine and check the official record status without exposing sensitive commercial data to the public web:

Public Schema Field	What `tradepact.network` Displays	What Is Strictly Excluded
1. `TradePactID`	The unique alphanumeric protocol reference (e.g., `20260813000001A`)	Internal ERP database keys or private customer account codes
2. Record Status	`Paid`, `Unpaid`, or `Unknown` (a terminated engagement renders as `Unknown`, never `Unpaid`)	Overdue day counts, ageing buckets, or subjective credit grades
3. Masked Invoice Number	Partially masked reference allowing the holder of the original invoice to cross-check it	Full unmasked commercial invoice serials or purchase order text
4. Invoice Date	The issue date of the registered invoice	Payment terms, due dates, or historical restructuring dates
5. Managing Participant	The name and logo of the network participant managing the engagement (e.g., InvoiceMediator)	Creditor company name, paying party name, emails, phone numbers, or S$ / SGD amounts

Built-In Anti-Enumeration and Freshness Protections

Beyond the five-field data boundary, tradepact.network enforces four technical safeguards at the application layer:

Search engine and cache exclusion: Every individual record lookup page is served with noindex and no-store HTTP headers and is excluded from sitemap.xml. Only the main landing page and /learn educational guides are indexable by search engines.
Byte-identical 404 responses: Whether someone queries a malformed TradePactID, an unknown identifier, or an unpublished record, the server returns a byte-identical 404 response (codebase/TradePact/docs/tradepact-app.md). External parties cannot probe the lookup endpoint as an oracle to discover whether a record exists.
Neutral link previews: Record pages, not-found pages, and unavailable pages share a single fixed Open Graph metadata block ("TradePact Network record") with no og:url. Pasting a link into a chat or email client never leaks the TradePactID, the invoice status, or the managing participant in a link preview.
Five-minute reconciliation and six-hour staleness cutoff: The projection reconciles against the execution rail every five minutes. If the projection ever goes more than six hours without a completed full sweep, tradepact.network automatically stops answering individual record lookups and returns a uniform 503 Temporarily Unavailable state rather than risk displaying an outdated Unpaid status for an invoice that was recently settled.

Why is settlement strictly non-custodial under the TradePact Protocol?

Under TradePact Protocol v1.0, settlement is strictly non-custodial: neither TradePact Network nor any participating engagement brand ever holds, processes, or takes custody of funds belonging to a creditor or a paying party, and all invoice payments are made directly between the commercial counterparties.

When a paying party reviews an invoice or agrees to a repayment schedule through a participant portal (pay.<domain>), the actual transfer of funds—whether by corporate bank transfer, GIRO, PayNow Corporate, or established card rails—flows straight from the buyer to the supplier's designated bank account.

This non-custodial boundary reinforced by Admission Criterion 4 (No conflicting position, tradepact.net/protocol) delivers three practical safeguards for both finance teams:

Zero fund commingling or intermediary settlement delay: Funds do not sit in a third-party escrow or collection clearing account waiting for disbursement.
No contingent collection bias: Because participants are prohibited from holding a financial interest in invoice outcomes or operating a debt purchase or debt collection business, engagement remains neutral and proportionate.
Clean ERP reconciliation: The supplier receives the exact payment directly from its customer's account, and once reconciled on the infrastructure rail, the public status on tradepact.network updates to Paid within the five-minute reconciliation window.

How does a shared receivables record compare against internal AR software and credit bureaus?

A shared receivables record differs from internal single-company AR software and traditional credit bureaus by providing a live, cross-party verification reference (TradePactID) governed by a neutral engagement protocol rather than a private single-ledger workflow or an adversarial post-default registry.

The table below compares the three models across six operational dimensions:

Feature / Dimension	Internal Single-Company AR Software (ERP / Billing Tools)	Credit Bureaus & Commercial Rating Agencies	Shared Receivables Record (TradePact Network)
Primary Purpose	Automate internal billing ledger and outbound reminders for one seller	Aggregate historical payment defaults and sell credit risk scores	Provide a neutral, shared protocol record (`TradePactID`) for post-issuance engagement, evidence, and resolution
Party Perspective & Governance	Single-sided (controlled entirely by the supplier's internal settings)	Third-party assessor (evaluates debtor risk for subscribers)	Neutral protocol standard (TradePact Protocol v1.0); participants hold no financial stake in outcomes
When Engagement Starts	Varies by company settings (often fragmented across email and ERP modules)	After late payment, default, or formal credit reporting	At invoice issuance, maintaining proportionate communication through to settlement
Counterparty Status Verification	None publicly verifiable; buyer must email the seller or log into a closed vendor portal	Paid credit report lookup exposing company identity and risk ratings	Free public lookup by `TradePactID` on tradepact.network showing only the 5-field closed schema
Dispute & Evidence Portability	Trapped in one company's ERP notes or scattered staff email inboxes	Formal credit file correction requests after a negative listing appears	Centralised, timestamped evidence log portable across network participants (e.g., InvoiceMediator to PaymentMediator)
Public Privacy Model	Private database (no public verification reference)	Publishes named company records and credit ratings to bureau users	Strict 5-field closed schema (`Paid`/`Unpaid`/`Unknown`, masked invoice number, date, participant); zero names or amounts; `noindex`/`no-store`

Frequently Asked Questions

Does looking up a TradePactID expose our company name or invoice amount?

No. Looking up a TradePactID on tradepact.network returns a strict five-field closed record: the TradePactID, current status (Paid, Unpaid, or Unknown), a masked invoice number, the invoice date, and the managing network participant. It never publishes the supplier's name, the paying party's name, contact details, or any S$ / SGD invoice amount. In addition, every record page carries noindex and no-store headers.

How does a shared receivables record preserve commercial relationships?

Under TradePact Protocol v1.0, engagement begins at invoice issuance with clear role disclosure and proportionate communication rather than sudden late-stage escalation. Because network participants (such as InvoiceMediator and PaymentMediator) operate under a neutral standard and are barred from holding a financial stake in invoice outcomes or running a debt collection business, both parties can resolve administrative bottlenecks and billing queries collaboratively.

What happens when a paying party flags a dispute on a TradePact record?

Under Principle 2 (Resolution) and Principle 3 (Evidence) of the TradePact Protocol, when a paying party raises a dispute or billing query through a participant portal (pay.<domain>), the position and its timestamped supporting context are recorded centrally and surfaced directly to the creditor for a decision. If a party wishes to dispute or correct a behavioural record, requests are handled by Late Payer Index under its published process at latepayerindex.com.

Can a shared receivables record work alongside our existing ERP and Peppol e-invoicing?

Yes. Pre-issuance e-invoicing standards (such as Peppol) and ERP billing modules generate and transmit the initial invoice. The TradePact shared receivables record governs the post-issuance lifecycle—assigning a TradePactID, logging follow-up communications centrally, coordinating dispute resolution or repayment plans through network participants, and projecting verified settlement status on tradepact.network while payments settle directly into your existing bank account.

Why does a TradePact record show "Unknown" instead of "Paid" or "Unpaid"?

On tradepact.network, a status of Unknown is displayed when an invoice engagement has been terminated on the network—ensuring a terminated matter is never falsely presented publicly as Unpaid—or when the current settlement state cannot be confirmed under protocol rules (codebase/TradePact/docs/tradepact-app.md).

Who can become a Participant on the TradePact Network?

Billing and accounting providers, business service firms, and trade bodies can apply to become network participants (participants@tradepact.net). Under the protocol's "Bring the brand. We run the rail." model, an admitted participant supplies a distinct engagement brand and domain (pay.<domain>), while all communication, evidence, resolution, and record-keeping run on central infrastructure operated by ChaseFlow Pte Ltd (tradepact.net/protocol).

Explore Structured Receivables Engagement in Action

Whether you are verifying a TradePactID on commercial correspondence or evaluating how protocol-governed follow-up and shared evidence records can bring clarity to your receivables workflow, see how the underlying execution rail operates from invoice issuance to resolution:

Watch the customer journey, the interactive demo and get started for free