Insights
The Token Is the Last Step: Why a Receivable Must Become a Reliable Asset Before It Goes On-Chain
POSCO-related trade-finance projects in July and August 2026 show a more useful model for tokenisation than simply putting invoice data on a blockchain. In the latest transaction, invoices, purchase orders, credit notes and shipment documents were reconciled before verified receivables were registered on-chain. The lesson is fundamental: a token can preserve and move an asset state, but the receivable first needs a reliable identity, evidence chain, current balance and ownership record.
This starts a temporary private draft. It is not public, listed for sale or shared automatically.
For a trade receivable, the first tokenisation question is whether there is a reliable asset to represent. Choosing a blockchain, token standard, holder model or payment rail comes after identifying the obligation, its current balance and the rights that can move.
Two separate POSCO-related initiatives illustrate that order. On 25 August 2026, POSCO International America, Olea and Intain announced an on-chain trade-finance transaction. According to the announcement, Intain reconciled invoices, purchase orders, credit notes and shipment documents before assets were verified and registered on Intain's Layer 1 network on Avalanche, within existing trade-finance workflows. Olea: Transaction announcement
In July, POSCO International and LG CNS had announced a separate proof of concept using actual trade data and Injective. It tested shared transaction records, receivable tokenisation, transfer and settlement controls, and AI-agent review of letters of credit and supporting documents. Different POSCO entities, partners and networks were involved; the two announcements should not be treated as one implementation or a competition result. POSCO: Proof of concept
Both put documentary reconciliation and controlled lifecycle processes ahead of the assumption that a token makes an asset reliable.
Reconstruct the commercial right before representing it
A receivable begins with goods or services and an obligation to pay under the transaction. A file can contain a contract, purchase order and confirmation, invoice, packing list, bill of lading or airway bill, warehouse receipt, origin or inspection certificate, delivery confirmation, letter of credit, insurance, credit and debit notes, payment instructions, bank messages, correspondence and later settlement evidence.
Those records perform different jobs. The order supports commercial origin; an invoice records the seller's requested amount; shipment evidence supports movement of goods; a letter of credit can create a separate bank undertaking subject to its own conditions. Credits and payments can reduce the balance, while financing can assign or encumber rights. Storing their hashes does not establish how those legal and economic objects relate.
Consider an invoice originally for $1,000,000. A $50,000 credit note, a $300,000 buyer payment and a later $25,000 adjustment leave $625,000 outstanding. Financing the remaining balance does not make the unchanged PDF a current $1 million receivable. The asset record must preserve the events rather than freeze the first amount.
| Illustrative event | Effect on the recorded balance |
|---|---|
| Invoice issued | $1,000,000 original amount. |
| Credit note | Reduce by $50,000. |
| Payment received | Reduce by $300,000. |
| Later agreed adjustment | Reduce by $25,000. |
| Current outstanding | $625,000, subject to the evidence and as-of date. |
Reconciliation should explain differences rather than conceal them
Orders can be amended; buyer and seller references may differ; names may be shortened; shipment quantities may not match orders; credits may refer to earlier invoice versions; and banks may use a letter-of-credit reference. The August transaction's announced reconciliation of invoices, orders, credits and shipments addressed that practical problem before registration.
In another illustrative file, an order specifies 10,000 units at $100, shipment evidence records 9,800 units, an invoice requests $1,000,000, and a credit note reduces it by $20,000. The resulting claim might be $980,000, but that is not a legal finding derived merely from subtraction. A contractual tolerance might allow all 10,000 units, part of the order might remain unshipped, or another invoice might exist. Preserve source values, relationships, discrepancy, resolution, reviewer and resulting state.
Not every mismatch indicates fraud. A trade name can differ from a legal name; quantities can reflect tolerance; credits can arrive after funding; one payment can cover two invoices, one order several invoices, or one invoice several shipments. An example with a $1,000,000 purchase order and $1,020,000 invoice could reflect an evidenced freight adjustment with a supporting amendment and an accepted review outcome. The explanation is more useful than silently replacing either value.
Verification needs an actor, method, scope and date
“Verified” can mean document authenticity, a field checked against another record, a calculation, buyer acknowledgement, agent approval, legal transferability review or bank settlement confirmation. These are distinct assertions.
A proposed evidence record should distinguish AI extraction, a system comparison of invoice and order, reviewer reconciliation of shipment quantity, incorporation of a credit note, an external buyer acknowledgement, ownership review and a balance confirmed as of a date. Certainty needs an attributable basis.
The July proof of concept reportedly used AI to review letters of credit and trade documents for potential errors before settlement. The August announcement described AI-assisted reconciliation before on-chain registration. Document classification and suggested names, references, quantities, amounts, credit notes, shipments and dates can help a reviewer; missing documents, currency conflicts and possible duplicates can be brought to attention.
That does not allow AI to create the legal obligation, establish accepted performance, ownership, enforceability or no set-off; permit assignment; eliminate another financier's claim; guarantee that the buyer cannot dispute; determine facility eligibility; equate token control with legal ownership; or conclude that a blockchain transfer satisfies assignment formalities. Those consequences depend on documents, law, external events and authorised judgement.
A unique token does not establish a unique receivable
A blockchain can record issuance, permissions, control or ownership changes, transfers, states and timestamps, freezes, redemptions and settlements. It can still be internally consistent while missing a credit note recorded in an ERP system, a shipment rejection or a legal determination that an assignment was invalid.
A hash supports integrity of a particular digital object. It does not prove genuineness, signatory authority, goods, delivery, buyer liability, current balance, ownership or absence of earlier financing. File identity and economic asset identity therefore need separate treatment.
Different PDFs or internal references can describe the same economic obligation. A supplier might present it through multiple financing channels, deliberately or through unreconciled arrangements. A meaningful uniqueness review connects seller and buyer, transaction and purchase order, invoice, amount and currency, shipment, due date, financing history and current ownership or security. A duplicate-file detector cannot reliably resolve all those relationships.
Nor can wallet control establish the legal bridge by itself. Transaction documents and law need to address original ownership, assignability and required form, debtor notice or consent, whether the token effects transfer or evidences an off-chain assignment, which registry or agreement controls, conflict rules, security, authorised correction and insolvency. A clear token holder can coexist with uncertain underlying entitlement.
Issuance is followed by administration and two cash events
The July announcement described a framework for receivables from actual trade to be issued, transferred, settled, traded and managed digitally, with permission-based administration, KYC/AML, investor eligibility and transfer restrictions. These were reported proof-of-concept functions, rather than a claim that every production market rule or risk had been resolved.
A proposed receivable lifecycle might distinguish creation, acknowledgement, eligibility, financing, partial payment, adjustment, arrears, collection and extinguishment. Other branches include dispute, repurchase, default, refinance, set-off and cancellation. Each state should be supported by events and history.
There are also two payment relationships: the financier advances cash to the supplier; the buyer later pays the currently entitled party. Conventional banking, stablecoins or another rail can carry them, but each event needs payer, payee, amount, currency, reference, value date and rail, partial-payment and reconciliation status, residual balance and any extinguishment.
Olea said the parties intended to explore stablecoin-enabled cross-border settlement. That was an intention, not evidence here of completed stablecoin settlement. Faster payment can potentially reduce correspondent, currency-conversion and reconciliation friction without establishing existence, ownership, balance, dispute status or discharge of the receivable. Reliable entitlement and payment instructions still come first.
Keep asset identity portable and the evidence accessible
The July Injective and August Intain/Avalanche projects show why an economic identity should survive the technical stack. A group could use different treasury and investor networks, a bank financing platform, ERP invoices and conventional payment rails. Economic asset IDs, document and ERP IDs, financing IDs, token IDs, transaction hashes and settlement references should be mapped without forcing one reference to describe everything.
A secondary holder also needs access to the supporting order, shipment, buyer acknowledgement, credits and balance changes, prior finance, transfer restrictions and the actor who checked each assertion. That evidence may be private, role-restricted or commercially sensitive; preserving a verifiable link does not require publishing all documents on-chain.
| Proposed evidence layer | Information to preserve |
|---|---|
| Commercial origin | Seller, buyer, contract/order and date, goods or services, delivery terms, currency, governing law and references. |
| Performance | Shipment, delivery or completion, inspection and warehouse evidence, acceptance, discrepancy, source system and review status. |
| Invoice and balance | Number/date, original amount, due date and terms, credits/debits, disputes, current outstanding amount, as-of date and state. |
| Ownership and transfer | Original creditor, holder, assignment/security, notice and consent, restrictions, prior finance, competing rights and evidence. |
| Financing | Financier/date, amount and advance rate, recourse, eligibility, reserves, repurchase duties, status and facility reference. |
| Digital representation | Network/identifier, issuance event, authorised holders and transfers, administration, freeze/pause and redemption, legal relationship to token control. |
| Settlement | Payment event, payer/recipient, amount/currency, rail and reference, reconciliation, residual balance and extinguishment. |
| Provenance | Documents and systems, extracted/AI-derived, externally confirmed and human-reviewed fields, method, reviewer, version, effective date and update time. |
This proposed evidence model can exist without blockchain. If tokenisation is appropriate later, a representation can refer to an already coherent right.
DaDepo's contribution begins with reviewable preparation
DaDepo can support document-backed private asset preparation and reviewable suggestions. Users can explain commercial origin, counterparties, amounts, adjustments, ownership evidence and known gaps through the source documents and reviewed information. A comprehensive external financing, ownership, settlement and lifecycle graph remains a proposed model, rather than an automatic existing product function.
External verification, legal diligence, banks, factoring platforms, marketplaces, blockchains and payment systems retain their own roles. The intended hand-off is a clearer evidence package that avoids reconstructing the same commercial facts every time, while preserving access restrictions and confirmation boundaries.
An Asset Passport does not authenticate all trade documents, confirm performance or buyer acceptance, establish enforceability, ownership, assignability, perfection or priority, prove absence of duplicate finance, complete assignment or confirm that a token conveys ownership. It does not issue tokens, operate a blockchain or factoring platform, fund the trade, provide custody, move transaction money or stablecoin settlement, guarantee payment, value the claim or recommend finance or investment. Legal, financial, investment, tax, accounting, banking, trade-finance, factoring, blockchain, issuance, custody, settlement, underwriting and valuation services need their own expressly identified and lawful basis. Tokenisation alone cannot establish title, priority, transferability or finality across jurisdictions.
Questions before financing or digital representation
Commercial facts and the current balance
- Seller: Is the creditor correctly identified?
- Buyer: Is the legal entity responsible for payment correctly identified?
- Commercial origin: Which contract, purchase order or transaction created the obligation?
- Performance: What evidence supports shipment, delivery or service completion?
- Invoice: Is the invoice number, amount, date and currency unambiguous?
- Adjustments: Are all credit notes, debit notes, rebates and returns reflected?
- Buyer position: Has the buyer acknowledged, accepted, disputed or adjusted the obligation?
- Current balance: What is actually outstanding and as of what date?
Entitlement and reconciliation
- Ownership: Who currently owns the receivable?
- Prior financing: Has it already been assigned, pledged, factored or otherwise financed?
- Transferability: Do legal or contractual restrictions affect transfer?
- Uniqueness: Can the economic receivable be distinguished from duplicate documents and duplicate financing?
- Reconciliation: Are purchase order, invoice, shipment and adjustment records consistent or are exceptions visible?
- Verification: Which facts were extracted, system-validated, externally confirmed or human-reviewed?
Digital administration and payment
- Token relationship: What right does control of the digital token or record legally represent?
- Permissions: Who may hold, transfer, freeze, redeem or administer the digital asset?
- Financing: Which facility or investor exposure is linked to the receivable?
- Settlement: How will debtor payment be matched to the current entitled party?
- Lifecycle: Will later adjustments, payments, disputes and transfers update the asset state?
- Provenance: Can every material field be traced to the correct source and version?
The August transaction's announced sequence began with reconciliation, while the separate July project explored controls and administration beyond issuance. Together they illustrate the need for evidence, a reviewed current balance, ownership and transfer rules, financing and payment around the representation. The token is a later step in making the asset digital; it cannot make an uncertain underlying right real.