Masked Invoice Lookup Privacy and Data Minimization on the TradePact Network

Masked invoice number lookup privacy on the TradePact Network is an architectural design that allows any commercial counterparty to check a TradePactID status online without exposing supplier names, buyer identities, contact details, or invoice amounts to the public web (TradePact Protocol v1.0, effective 1 January 2026, operated by ChaseFlow Pte Ltd, UEN 202542183C, in Singapore). When a finance controller or accounts payable team queries a 15-character TradePactID on tradepact.network, the public registry returns a closed five-field record—TradePactID, status (Paid, Unpaid, or Unknown), masked invoice number, invoice date, and managing participant—protected by noindex directives, no-store cache headers, and anti-enumeration rate limits.

This technical and governance guide is written for chief financial officers, finance directors, accounts payable (AP) controllers, compliance officers, and commercial counterparties in Singapore and international trade corridors who need to verify third-party invoice correspondence while maintaining strict commercial confidentiality.

Key Takeaways (TL;DR)

• Closed five-field public schema: Every TradePact Network invoice status lookup on tradepact.network is assembled strictly from five permitted fields (TradePactID, Status, Masked Invoice Number, Invoice Date, and Managing Participant). No additional database columns can surface publicly.
• Zero commercial party or amount leakage: The public lookup never publishes creditor names, paying-party names, individual contact persons, email addresses, telephone numbers, line-item descriptions, or invoice monetary values (whether in S$ / SGD or any other currency).
• Three-way AP matching via invoice masking: Masking middle characters of the supplier's document number (such as INV-***-0492 or INV-•••-8812) lets an internal accounts payable team match a notice against its own enterprise resource planning (ERP) ledger while preventing external observers from reading or guessing sequential invoice numbers.
• Search-engine and caching blocks: Individual record pages serve HTTP Cache-Control: no-store and X-Robots-Tag: noindex headers, omit record-specific Open Graph preview tags, and are excluded from sitemap.xml and robots.txt crawl paths.
• Anti-scraping and oracle resistance: Route-level IP rate limiting and byte-identical 404 responses across malformed, unknown, and unpublished identifiers prevent automated bots from enumerating records.
• Non-custodial, direct settlement: TradePact Network is a shared protocol and record framework—never a debt collector, credit bureau, or payment processor. All invoice payments settle directly between the paying party and the supplier.

---

Why Does Public Invoice Status Verification Require Strict Data Minimization?

Public invoice status verification requires strict data minimization because accounts payable teams need an immediate, unauthenticated way to confirm that a third-party payment notice is legitimate without broadcasting confidential B2B supply-chain relationships or financial figures to the public internet. In commercial trade, suppliers frequently engage specialized third-party brands—such as InvoiceMediator or PaymentMediator—to manage routine post-issuance invoice follow-up under TradePact Protocol v1.0.

When an accounts payable department receives a payment reminder from an external engagement brand rather than the supplier's own domain, its immediate operational duty is verification. Before releasing funds or responding to a notice, the controller must confirm two facts: first, that the communication represents a genuine commercial invoice registered by an authorized network participant; and second, whether the current network state of that invoice is Unpaid or Paid.

Historically, B2B verification methods forced an unacceptable trade-off between verification friction and commercial exposure:

1. Siloed supplier portals require the buyer's AP team to register accounts, manage multi-factor authentication credentials across dozens of different vendor systems, and wait for manual password resets just to view a single invoice status.
2. Public credit registries or default lists publish company names and claim amounts openly, turning routine administrative reconciliation into reputational damage.

Masked invoice lookup privacy is the engineering and governance principle that resolves this tension by separating verification metadata from confidential commercial data. By restricting public lookup responses to non-sensitive structural identifiers that only the actual transaction counterparties can contextualize, tradepact.network enables instant zero-login verification while upholding statutory privacy standards, data minimization principles, and technical access controls.

---

What Exactly Does the 5-Field Closed Public Record Contract Return?

The five-field closed public record contract on tradepact.network returns exclusively the TradePactID, the record Status, the Masked Invoice Number, the Invoice Date, and the Managing Participant (codebase/TradePact/docs/tradepact-app.md). At the application layer, the public lookup response is constructed field by field from an explicit allow-list (TRADEPACT_PUBLIC_RECORD_FIELDS) rather than serializing an entire database row, ensuring that internal administrative columns can never leak into a public page or JSON response by accident.

For full details on reading each field during routine reconciliation, see our companion guide on what a TradePactID tells you. Below is how each of the five fields operates under the privacy architecture.

1. TradePactID (15-Character Canonical Identifier)

A TradePactID is a 15-character alphanumeric reference code (formatted as YYYYMMDDNNNNNNA, such as 20260813000001A) assigned when an eligible commercial invoice is registered on the network through ChaseFlow infrastructure. It contains the registration date segment (YYYYMMDD), a six-digit sequence number (NNNNNN), and a single uppercase check letter (A–Z). Because the identifier is completely opaque regarding who issued or received the invoice, possessing or viewing a TradePactID reveals no commercial identity.

2. Status (Paid, Unpaid, or Unknown)

The status field reflects the current lifecycle state of the shared receivables record:

• Unpaid: The invoice is currently registered for active follow-up under the TradePact Protocol and settlement has not yet been confirmed.
• Paid: Settlement has been confirmed by the supplier or verified through payment evidence, closing active follow-up.
• Unknown: The record is no longer under active protocol management (for example, if the supplier withdrew or terminated follow-up). Crucially, a terminated record maps strictly to Unknown—never Unpaid—so an ended engagement is never misrepresented publicly as an outstanding debt (codebase/TradePact/docs/tradepact-app.md). If an invoice is archived after resolution, the lookup preserves the status held immediately before archiving.

3. Masked Invoice Number (Prefix and Suffix Preservation)

Instead of publishing the full billing reference from the supplier's accounting software, the record displays a masked invoice number (for example, INV-***-0492 or INV-•••-8812). This field retains the leading prefix and trailing digits while obfuscating the interior characters.

4. Invoice Date (YYYY-MM-DD)

The record displays the original issue date of the invoice in ISO 8601 calendar format (YYYY-MM-DD). Combined with the masked invoice number, the issue date gives an internal finance team a second deterministic data point to confirm that the record matches an entry in its accounts payable sub-ledger.

5. Managing Participant

The fifth field names the authorized TradePact Network participant responsible for managing communication on the invoice—such as InvoiceMediator or PaymentMediator—along with participant metadata verified by the network registry. This allows the recipient to confirm that the domain in the email or letter they received (pay.<domain>) belongs to a legitimate participant governed by how the TradePact Protocol works.

---

What Commercial Data Is Permanently Excluded from TradePactID Lookups?

TradePactID lookups permanently exclude all counterparty legal names, individual contact details, commercial line items, banking coordinates, and monetary invoice amounts from both the rendered HTML page and the JSON lookup endpoint (tradepact.network). Even if an external party obtains a valid 15-character TradePactID, querying the public registry yields zero information about who owes money, who issued the bill, or the financial size of the transaction.

Specifically, the following categories of commercial and personal data are never published on tradepact.network:

• Creditor (supplier) identity: Legal entity name, trading name, Singapore UEN or foreign company registration number, tax registration number, and business address.
• Paying-party (buyer) identity: Legal entity name, parent or subsidiary group names, registration numbers, and billing address.
• Personal contact information: Names of finance personnel, accounts payable clerks, or company directors; business email addresses; direct or mobile telephone numbers.
• Financial figures and currencies: Total invoice value, outstanding balance, tax or GST components, credit notes, or currency denomination (such as S$ / SGD, US$ / USD, or £ / GBP).
• Contractual and line-item details: Product or service descriptions, purchase order numbers, delivery receipts, unit pricing, or commercial terms.
• Dispute narratives and uploaded evidence: While parties can submit payment confirmation or flag a commercial dispute through the dedicated participant portal (pay.<domain>), the substance of those communications and any supporting documents remain restricted to authorized parties within the shared receivables record workflow.

By enforcing this boundary at the protocol level, TradePact Network ensures that public status verification adheres to strict data minimization principles without creating a public ledger of private commercial obligations.

---

How Does Invoice Number Masking Enable Internal AP Matching Without Public Leakage?

Invoice number masking enables internal accounts payable matching by preserving the recognizable structural edges of a supplier's document identifier—its prefix and final digits—while redacting the middle sequence so external parties cannot reconstruct or guess the full reference. This technique balances operational usability for the legitimate buyer against zero-knowledge privacy toward the outside world.

How the Legitimate Buyer Uses a Masked Reference

When an accounts payable controller in Singapore receives a follow-up email referencing TradePactID 20260813000001A and checks it on tradepact.network, the screen displays:

• Status: Unpaid
• Invoice Number: INV-***-0492
• Invoice Date: 2026-08-13
• Managing Participant: InvoiceMediator

Inside the buyer's own accounting system (such as Xero, NetSuite, or SAP), the AP clerk filters open vendor bills dated 13 August 2026 whose reference starts with INV- and ends in 0492. Within seconds, the clerk locates invoice INV-2026-980492 from a known supplier for S$14,500.00, verifies that the goods were received, and confirms that the notice from InvoiceMediator is authentic. For step-by-step verification procedures, see our guide on how to verify third-party invoice correspondence.

Why an External Observer Learns Nothing

Consider what happens if an unauthorized third party views the exact same lookup result (INV-***-0492, dated 2026-08-13, Unpaid):

1. No entity link: Because neither the supplier's name nor the buyer's name is present on the record, the external observer cannot link INV-***-0492 to any business.
2. No sequential inference: Many companies issue sequential invoice numbers (for example, INV-2026-980491, INV-2026-980492, INV-2026-980493). Masking the interior characters prevents anyone from using the public lookup record to deduce a supplier's total billing volume or full invoice numbering scheme.
3. No financial exposure: Without an amount or currency field, a status of Unpaid gives an outside viewer zero insight into whether the underlying invoice is a routine S$50 administrative adjustment or a major commercial contract.

---

What Technical Safeguards Prevent Search Engine Indexing, Caching, and Enumeration?

TradePact Network prevents search engine indexing, browser caching, link-preview leakage, and automated enumeration through five layered HTTP and application controls enforced across tradepact.network (codebase/TradePact/docs/tradepact-app.md). Data minimization in the JSON schema is reinforced by transport and rendering rules that keep individual lookup records off search engine results pages (SERPs) and out of shared caches.

1. X-Robots-Tag: noindex and Strict robots.txt Isolation

While the TradePact Network landing page (/) and educational guides under /learn are open to search engines so finance teams can research the protocol, every individual record lookup page, 404 not-found page, 410 page, and 503 error page serves a strict noindex directive. Furthermore, the site's robots.txt explicitly disallows crawling of all lookup paths (Disallow: /), opening only the exact root landing page (/$), explicitly declared static favicon/share assets, and the /learn educational directory. Individual TradePactID URLs are never included in sitemap.xml.

2. Cache-Control: no-store on All Record Responses

Every record lookup response sets no-store caching directives (Cache-Control: no-store, no-cache, must-revalidate). This instructs browsers, corporate proxy servers, and content delivery networks (CDNs) not to retain copies of the lookup response on disk or in shared memory. In addition, when an invoice changes state—for example, when a supplier marks an invoice settled or a dispute is resolved—the publisher pushes the update immediately and kept records reconcile every five minutes (codebase/TradePact/docs/tradepact-app.md), ensuring that a fresh lookup never serves stale status data.

3. Redacted Open Graph and Social Share Metadata

When finance staff paste a URL into Slack, Microsoft Teams, WhatsApp, or an email client, the messaging platform typically fetches the page's Open Graph (og:title, og:description, og:url) tags to generate a rich preview card. If a lookup page embedded the TradePactID or invoice status inside those meta tags, messaging servers would log and preview the status before the recipient even clicked the link.

To prevent metadata leakage, all record pages, not-found pages, and unavailable pages on tradepact.network return one identical, static metadata block titled simply "TradePact Network record" with no og:url attribute (codebase/TradePact/docs/tradepact-app.md). Consequently, pasting a lookup link into a chat channel never reveals the TradePactID, never previews whether the invoice is Paid or Unpaid, never names the managing participant, and cannot even confirm whether the record exists in the database.

4. Byte-Identical 404 Responses (Anti-Oracle Design)

In poorly designed lookup systems, querying a syntactically invalid reference returns a "400 Bad Format" error, querying a non-existent ID returns "404 Not Found", and querying an unpublished record returns "403 Forbidden". Attackers exploit those differences as an oracle to map out active records.

On tradepact.network, every public miss is byte-identical (codebase/TradePact/docs/tradepact-app.md). Whether a request contains a malformed identifier, a well-formed TradePactID that does not exist, an internal invoice that has not been registered on the network, or an unknown URL path, the server returns the exact same 404 response body. Furthermore, if the underlying status projection has not completed a healthy reconciliation sweep within its six-hour freshness window, the site returns HTTP 503 Temporarily Unavailable rather than a false 404, ensuring the registry never makes an inaccurate claim that a record does not exist.

5. Shared-Budget IP Rate Limiting and Method Restrictions

Public status routes on tradepact.network accept GET and HEAD requests only; all public write attempts are rejected at the router level. Both the HTML record view and the JSON lookup endpoint share a single route-level rate-limiting budget per IP address (codebase/TradePact/docs/tradepact-app.md). Combined with the 15-character date-and-checksum structure of a TradePactID, shared rate limiting stops automated scripts from brute-forcing or scraping lookup endpoints.

---

How Do Counterparties Move from Public Status Lookup to Secure Resolution?

Counterparties move from a public status lookup on tradepact.network to actual invoice resolution through the managing participant's token-scoped portal (pay.<domain>) or direct communication with the supplier. This two-tier architecture separates public verification from authenticated transaction handling.

1. Tier 1: Unauthenticated Public Verification (tradepact.network). Anyone holding a TradePactID can verify that the notice is genuine, check whether the status is Paid, Unpaid, or Unknown, match the masked invoice number and invoice date against internal AP records, and confirm the managing participant brand.
2. Tier 2: Token-Scoped Participant Portal (pay.<domain>). The correspondence sent to the paying party by the managing participant (such as InvoiceMediator or PaymentMediator) contains a secure link to the participant's dedicated portal. Within that scoped session, the paying party can review payment instructions, confirm settlement, flag a structured commercial dispute, or use the "I don't recognize this company" reporting link (codebase/TradePact/docs/tradepact-app.md).

When a recipient submits an "I don't recognize this company" report on a live invoice, the portal forwards the notification directly to the declaring supplier as an action item so the business can confirm the invoice and contact its customer directly. Neither TradePact Network nor ChaseFlow decides the validity of an underlying commercial claim, and no participant ever holds or processes client funds—all invoice settlements occur 100% directly between the buyer and the supplier (TradePact Protocol v1.0).

Want to see how structured invoice follow-up and TradePactID registration work from the supplier's side? Watch the customer journey, the interactive demo and get started for free.

---

Frequently Asked Questions (FAQ)

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

No. A TradePactID lookup on tradepact.network never displays the supplier's name, the buyer's name, individual contact details, line-item descriptions, or the invoice amount. The closed five-field public schema returns only the TradePactID, the status (Paid, Unpaid, or Unknown), a masked invoice number, the invoice issue date (YYYY-MM-DD), and the managing network participant.

Why is the invoice number partially masked on tradepact.network?

The invoice number is partially masked (for example, INV-***-0492 or INV-•••-8812) to support masked invoice number lookup privacy. Preserving the prefix and final digits allows the legitimate buyer's accounts payable team to match the record against its internal ERP ledger and the invoice date, while preventing external viewers from reading full document identifiers or guessing sequential invoice numbers.

Can Google or other search engines index our TradePactID status page?

No. Every individual record page on tradepact.network serves an HTTP X-Robots-Tag: noindex directive and Cache-Control: no-store header, is disallowed in robots.txt, and is excluded from sitemap.xml (codebase/TradePact/docs/tradepact-app.md). Search engines can index the main landing page and /learn educational guides, but never individual invoice lookup records.

How do I check TradePactID status if I received a notice from InvoiceMediator or PaymentMediator?

To check TradePactID status, copy the 15-character alphanumeric code (such as 20260813000001A) from the correspondence and enter it into the lookup bar at tradepact.network. Verify that the returned status, masked invoice number, and invoice date match your accounts payable records, and confirm that the listed Managing Participant matches the sender brand (InvoiceMediator or PaymentMediator).

What does a status of "Unknown" mean on a TradePact Network invoice status lookup?

A status of Unknown means the TradePactID is registered on the network, but active follow-up under the TradePact Protocol has been terminated or closed without a confirmed payment state. Under network rules, terminated engagements map strictly to Unknown rather than Unpaid so that discontinued follow-up is never publicly displayed as an unpaid obligation.

Is TradePact Network a credit bureau, debt collector, or payment processor?

No. TradePact Network is a shared protocol and receivables record framework operated by ChaseFlow Pte Ltd in Singapore (tradepact.net/protocol). Network participants are prohibited from purchasing debt, acting as enforcement or collection agencies, operating as a credit bureau, or holding customer funds. Every invoice payment settles directly between the buyer and the supplier.

---

Experience Structured, Privacy-First Receivables Management

TradePact Network gives commercial counterparties instant confidence in invoice status verification while protecting confidential business relationships through strict five-field data minimization. For suppliers and finance teams looking to onboard invoices onto the protocol through ChaseFlow's managed receivables infrastructure, explore the workflow firsthand:

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