29 Aug 2026

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.

Create a structured receivable record

This starts a temporary private draft. It is not public, listed for sale or shared automatically.

Credit manager Receivable Learn

Tokenisation discussions often start with the token.

Which blockchain should be used?

Which token standard?

Who can hold it?

Can it settle in stablecoins?

Can it trade?

Those are reasonable questions.

They are usually not the first questions.

For a trade receivable, the first question is more basic:

Is there a reliable asset to tokenise?

Two POSCO-related projects in the summer of 2026 make that distinction unusually visible.

On 25 August, POSCO International America, Olea and Intain announced an on-chain trade-finance transaction in which trade receivables were converted into tokenised digital assets and recorded on-chain. Before that happened, Intain reconciled information across invoices, purchase orders, credit notes and shipment documents. The assets were then verified and registered on Intain’s Layer 1 network on Avalanche, with the process integrated into existing trade-finance workflows. Olea: POSCO, Olea and Intain Complete Landmark On-Chain Trade Finance Transaction

A month earlier, POSCO International and LG CNS had announced a separate proof of concept using real trade data. That initiative tested a shared ledger for transaction information, tokenisation of accounts receivable, transfer and settlement controls, and AI-agent review of letters of credit and supporting trade documentation using Injective. POSCO Group Newsroom: POSCO INTERNATIONAL Partners with LG CNS to Complete PoC for Blockchain and AI-Based Global Trade Finance Technologies

The two projects involve different POSCO entities, different technology partners and different blockchain infrastructure.

They should not be treated as one continuous implementation.

But they point toward the same architecture.

The useful sequence is not:

Invoice PDF
    ->
Token
    ->
Liquidity

It is closer to:

Commercial transaction
    ->
Documents and external evidence
    ->
Reconciliation
    ->
Identified receivable
    ->
Verification
    ->
Current asset state
    ->
Digital ownership / control record
    ->
Financing
    ->
Settlement

That difference matters far beyond trade finance.

The token is not where the asset begins

A receivable begins with a commercial obligation.

A seller supplies goods or services.

A buyer becomes obliged to pay according to the governing transaction.

An invoice may document that obligation.

But the invoice is not the whole transaction.

A typical trade-finance file can include:

purchase order;
sales contract;
order confirmation;
invoice;
packing list;
bill of lading;
airway bill;
warehouse receipt;
certificate of origin;
inspection certificate;
delivery confirmation;
letter of credit;
insurance document;
credit note;
debit note;
payment instruction;
bank message;
correspondence;
and later settlement evidence.

Different documents answer different questions.

The purchase order can support the commercial origin.

The invoice states an amount requested by the seller.

The shipment document can support movement of goods.

A letter of credit may create a separate bank payment undertaking subject to its own terms.

A credit note can reduce what is owed.

A payment record may prove that part of the receivable no longer exists.

A financing agreement can transfer or encumber rights.

No blockchain can infer the legal and economic relationship among those documents merely because their hashes are stored on-chain.

The asset must first be reconstructed.

A receivable is a state, not a file

Suppose a seller issues an invoice for $1 million.

A week later, a $50,000 credit note is issued.

The buyer then pays $300,000.

The seller finances the remaining balance.

Later, another $25,000 adjustment is agreed.

The invoice PDF can remain exactly the same throughout.

The economic asset changes repeatedly.

A useful record might show:

Original invoice amount:        $1,000,000
Credit note:                      -$50,000
Payment received:                -$300,000
Later adjustment:                 -$25,000
Current outstanding amount:       $625,000

If the token continues to represent "$1 million invoice" after those events, tokenisation has preserved the wrong state very efficiently.

That is why asset identity and lifecycle come before token identity.

The token should point to the current economic object.

It should not freeze the first document that happened to describe it.

Reconciliation is not clerical work

Trade finance often contains multiple versions of the same event.

A seller may record one invoice number.

The buyer may use another internal reference.

The shipping document may show a slightly different quantity.

The purchase order may have been amended.

The invoice may use a shortened buyer name.

The credit note may refer to an earlier invoice version.

The bank may identify the transaction by a letter-of-credit number rather than the invoice number.

This creates a reconciliation problem.

The 25 August POSCO International America transaction is interesting because the announced workflow explicitly placed reconciliation before on-chain registration.

Intain said its platform reconciled:

invoices;
purchase orders;
credit notes; and
shipment documents.

That is the important part.

A token can be unique while the underlying economic asset is duplicated.

A token can be immutable while the source data is wrong.

A token can have a clear holder while the assignability of the underlying receivable is uncertain.

A token can show a balance while a later credit note exists outside the chain.

Reconciliation is therefore not an administrative inconvenience around tokenisation.

It is part of asset creation.

Four documents can describe one receivable

Consider a simplified trade transaction.

Purchase order:     10,000 units at $100
Shipment evidence:   9,800 units shipped
Invoice:             $1,000,000
Credit note:            $20,000

What is the asset?

The purchase order suggests $1 million.

The shipment record suggests $980,000 of delivered goods.

The invoice requests $1 million.

The credit note reduces the invoiced amount by $20,000.

Perhaps the correct receivable is $980,000.

Perhaps the buyer accepted all 10,000 units under a contractual tolerance.

Perhaps part of the order remains to be shipped.

Perhaps there is another invoice.

The documents need interpretation.

The correct answer does not come from choosing the newest PDF.

A structured workflow should preserve:

the source values;
their relationships;
discrepancies;
resolution;
reviewer;
and resulting current asset state.

That is provenance.

Verification is stronger when it is explicit

The word verified can hide many different actions.

A document may be verified as authentic.

A field may be verified against another source.

A calculation may be verified.

A buyer may confirm an obligation.

A custodian or verification agent may approve an asset record.

A lawyer may confirm transferability.

A bank may confirm settlement.

These are not the same assertion.

A reliable receivable record should therefore avoid:

Verified: Yes

as the whole answer.

It should be possible to know:

Invoice extracted: AI
Invoice amount confirmed against PO: System rule
Shipment quantity reconciled: Reviewer
Credit note incorporated: Yes
Buyer acknowledgement: External event
Ownership evidence reviewed: Legal / operational review
Current balance confirmed as of: [date]

The goal is not to create more bureaucracy.

It is to make certainty attributable.

AI can establish consistency without creating legal truth

The POSCO projects also show why AI and blockchain perform different jobs.

In the July POSCO International and LG CNS proof of concept, an AI agent was used to review letters of credit and trade documents and detect potential errors before settlement.

In the August Olea and Intain transaction, AI-assisted infrastructure was used to reconcile information across multiple commercial documents before the receivable was registered on-chain.

Those are sensible uses of AI.

AI can help:

classify documents;
extract invoice numbers;
identify buyer and seller names;
read purchase-order references;
compare quantities;
compare amounts;
find credit notes;
identify shipment references;
detect missing documents;
reconcile dates;
flag inconsistent currencies;
identify duplicate files;
identify potentially duplicated receivables;
and prepare exceptions for human review.

But AI does not create the underlying legal obligation.

It should not independently conclude that:

goods were legally accepted;
the seller owns the receivable;
the receivable is enforceable;
no set-off right exists;
assignment is permitted;
another financier has no prior claim;
the buyer cannot dispute payment;
the receivable is eligible under a financing agreement;
the token holder legally owns the receivable;
or a blockchain transfer satisfies every legal requirement for assignment.

AI can organise evidence.

The legal and commercial consequence still depends on the documents, applicable law, external events and human judgement.

Blockchain can preserve state without being the source of the state

A blockchain is particularly useful for certain questions.

It can help record:

issuance;
ownership changes;
permissions;
transfer history;
status changes;
timestamps;
asset freezes;
redemptions;
and settlement events.

That can reduce the problem of multiple parties maintaining incompatible records.

But a chain only knows what is submitted to it.

If the buyer issues a credit note in an ERP system and nobody updates the digital asset, the blockchain can remain perfectly internally consistent and economically wrong.

If a shipment is rejected, the chain does not discover that fact by itself.

If a court later determines that an assignment was invalid, the token history does not reverse the legal conclusion.

This suggests a useful division of labour:

Documents and systems
    ->
Evidence

AI and reconciliation
    ->
Structured asset state

Human / external validation
    ->
Authoritative confirmations where required

Blockchain
    ->
Shared lifecycle and control record

The value comes from connecting the layers.

A hash proves less than many people think

Hashing is useful.

A cryptographic hash can demonstrate that a file has not changed since a particular commitment was created.

That is valuable for provenance.

But a hash does not prove that:

the document is genuine;
the signatory had authority;
the underlying goods exist;
delivery occurred;
the buyer accepts liability;
the receivable is still outstanding;
the seller owns it;
or the receivable has not been financed elsewhere.

It proves integrity of a digital object.

It does not prove the economic truth of the asset described by that object.

This is why tokenisation architectures need both document identity and economic asset identity.

Duplicate financing is an asset problem, not a file problem

Trade receivables are vulnerable to duplicate financing for a simple reason.

The same economic obligation can appear in several documents.

A seller can create two PDFs describing the same receivable.

A supplier can finance an invoice through one channel and later present a differently formatted document to another lender.

Two systems can assign different internal IDs to the same commercial obligation.

No duplicate-file detector will reliably solve that.

The relevant uniqueness test has to connect:

seller;
buyer;
underlying transaction;
purchase order;
invoice;
amount;
currency;
shipment;
due date;
financing history;
and current ownership or security status.

A unique token does not automatically create a unique receivable.

The economic asset needs a durable identity before token issuance.

The July POSCO proof of concept makes lifecycle explicit

POSCO International’s July announcement is useful because it described more than issuance.

The company said it validated a framework under which receivables generated from actual trade transactions could be:

issued;
transferred;
settled;
traded;
and managed as digital assets.

The project also tested:

permission-based asset management;
KYC and AML procedures;
investor eligibility screening;
and transfer restrictions.

That is closer to market infrastructure than a token minting demo.

It recognises that a financial asset needs controls throughout its lifecycle.

The asset can have a holder.

The holder can change.

The holder may need to satisfy eligibility requirements.

Transfers may need to be restricted.

Settlement can extinguish or close the asset.

The record needs administration after issuance.

That is what makes a digital asset operational.

Ownership needs a legal bridge

A blockchain can answer:

Which wallet controls this token?

The legal system asks another question:

What rights does control of that token create?

Those questions may be aligned by the transaction documents and applicable law.

They should not be assumed to be identical.

For a tokenised receivable, the legal architecture may need to establish:

who originally owns the receivable;
whether the receivable can be assigned;
what form the assignment must take;
whether debtor notification or consent is required;
whether the token itself effects transfer;
whether the token is only evidence of an off-chain assignment;
which registry or agreement is authoritative;
what happens if the token record conflicts with another record;
how security interests are represented;
who can correct errors;
and what happens in insolvency.

A reliable digital asset therefore needs a legal bridge between token control and the underlying right.

Without that bridge, the token may be an excellent operational record of an uncertain legal position.

Current balance is as important as original amount

Trade-finance systems often emphasise origination.

But the receivable changes after origination.

A useful lifecycle needs to capture:

Created
    ->
Buyer acknowledged
    ->
Eligible for financing
    ->
Financed
    ->
Partially paid
    ->
Adjusted
    ->
Overdue
    ->
Collected
    ->
Extinguished

Not every receivable follows that sequence.

Some may be disputed.

Some may be repurchased.

Some may default.

Some may be refinanced.

Some may be offset.

Some may be cancelled.

The important point is that the current state should be derived from events, not manually overwritten without history.

That makes later investor diligence much stronger.

Settlement should close the economic loop

Tokenisation is often described as improving settlement.

For receivables, there are two settlements to think about.

First:

Financier
    ->
Supplier

The supplier receives funding against the receivable.

Second:

Buyer
    ->
Current entitled party

The debtor ultimately pays.

Those cash flows may happen through conventional bank rails, stablecoins or another payment system.

The asset record should reconcile the payment event regardless of the rail.

A useful settlement record can include:

payer;
payee;
amount;
currency;
payment reference;
value date;
bank or settlement rail;
partial-payment status;
reconciliation status;
residual balance;
and whether the receivable is extinguished.

A token that moves instantly but cannot be reconciled against the debtor payment has not solved the whole problem.

Stablecoins are a settlement layer, not an asset-validation layer

Olea said the parties intend to explore further opportunities including stablecoin-enabled cross-border settlement.

That is a natural next step.

Trade finance frequently contains payment delay, correspondent banking complexity, currency conversion and reconciliation.

Programmable settlement can reduce some of that friction.

But stablecoin settlement does not answer:

whether the receivable exists;
who owns it;
how much remains outstanding;
whether it is disputed;
or whether the payment satisfies the underlying obligation.

The sequencing remains important:

Reliable asset
    ->
Reliable entitlement
    ->
Reliable payment instruction
    ->
Settlement

Faster money does not fix uncertain asset data.

Multiple networks make portable asset identity more important

The two POSCO-related initiatives used different infrastructure.

The July POSCO International and LG CNS proof of concept used Injective.

The August POSCO International America, Olea and Intain transaction used Intain’s Layer 1 network on Avalanche.

That should not be read as a competition result.

They are separate projects.

But the coexistence of multiple networks reveals another infrastructure question.

What happens if the same corporate group eventually uses:

one network for internal treasury;
another for trade-finance investors;
a bank platform for financing;
an ERP system for invoicing;
and conventional payment rails for settlement?

The asset needs an identity that survives the technology stack.

Otherwise the market merely replaces disconnected databases with disconnected chains.

A durable asset record should therefore distinguish:

Economic asset ID
External document IDs
ERP IDs
Financing IDs
Token IDs
Blockchain transaction IDs
Settlement references

They can all refer to the same receivable.

None needs to become the universal identifier for everything.

They need to be linked.

Provenance has to travel with the asset

One of the strongest promises of tokenisation is portability.

An asset can move to a new holder.

That creates a danger.

The token may move more easily than the evidence supporting it.

A secondary investor cannot rely on the original supplier’s operational knowledge.

The investor may need to know:

which purchase order supports the transaction;
which shipment document supports performance;
whether the buyer acknowledged the amount;
whether a credit note exists;
whether the balance changed;
which financing has already occurred;
whether the receivable is transferable;
and who verified each fact.

The token should therefore not become a detached symbol.

It should remain connected to an evidence graph.

That evidence may be private.

It may require role-based access.

It may contain commercially sensitive information.

The solution is not necessarily to put every document on-chain.

The solution is to preserve a verifiable link between the market object and the evidence behind it.

A receivable Asset Passport should exist before tokenisation

For DaDepo, the practical lesson is straightforward.

The useful object is not:

Tokenised invoice

It is a structured receivable Asset Passport that can later support tokenisation if appropriate.

A useful record could include the following layers.

Commercial origin

seller;
buyer;
underlying contract;
purchase order;
order date;
goods or services;
delivery terms;
currency;
governing law;
and commercial references.

Performance evidence

shipment document;
delivery confirmation;
service completion;
inspection record;
warehouse document;
acceptance record;
discrepancy;
source system;
and review status.

Invoice and receivable

invoice number;
invoice date;
original amount;
due date;
payment terms;
credit notes;
debit notes;
disputes;
current outstanding amount;
as-of date;
and status.

Ownership and transfer

original creditor;
current holder;
assignment;
security interest;
debtor notification;
consent where relevant;
transfer restrictions;
prior financing;
competing rights;
and ownership evidence.

Financing

financier;
financing date;
financed amount;
advance rate;
recourse status;
eligibility criteria;
reserve;
repurchase obligation;
financing status;
and facility reference.

Digital representation

network;
token or asset identifier;
issuance event;
authorised holders;
transfer restrictions;
administrative authority;
freeze or pause status;
redemption status;
and relationship between token control and legal ownership.

Settlement

payment event;
payer;
recipient;
amount;
currency;
payment rail;
payment reference;
reconciliation;
residual balance;
and extinguishment status.

Provenance

source document;
source system;
extracted field;
AI-derived field;
externally confirmed field;
human-reviewed field;
verification method;
reviewer;
version;
effective date;
and last updated timestamp.

This record can exist without blockchain.

If the asset later becomes tokenised, the digital representation can attach to an already coherent economic object.

The market needs exception handling more than perfect automation

Trade assets are messy.

Not every mismatch is fraud.

An invoice may use a trade name rather than the full legal name.

A shipping quantity may differ because of contractual tolerance.

A credit note may arrive after financing.

A buyer may pay two invoices in one transfer.

A purchase order may cover several invoices.

One invoice may cover several shipments.

The objective should not be to force every transaction into an artificial perfect match.

A robust system should expose exceptions.

For example:

PO amount:                  $1,000,000
Invoice amount:             $1,020,000
Reason:                     Freight adjustment
Supporting amendment:      Present
Reviewer status:            Accepted

That is more useful than silently overwriting one number.

Asset infrastructure needs explainable differences.

What DaDepo can contribute

DaDepo does not need to operate a blockchain to benefit from the lesson.

Its role can be upstream and technology-neutral.

DaDepo can help users transform a document package into an Asset Passport that connects:

commercial origin;
counterparties;
documents;
current receivable;
adjustments;
ownership;
financing;
settlement;
lifecycle;
and provenance.

If an external blockchain, factoring platform, bank, trade-finance marketplace or payment system later becomes involved, the Asset Passport can preserve the evidence surrounding the asset.

That creates a cleaner hand-off:

Documents
    ->
DaDepo Asset Passport
    ->
Verification / diligence
    ->
External financing infrastructure
    ->
Digital representation
    ->
Settlement
    ->
Lifecycle update

The important architectural principle is that the external system should not need to reinterpret the original document pack from scratch every time.

What DaDepo does—and does not do

Creating or reviewing a receivable Asset Passport does not mean that DaDepo has:

authenticated every trade document;
confirmed that goods were delivered;
confirmed buyer acceptance;
established that a receivable is legally enforceable;
confirmed that a seller owns the receivable;
determined that assignment is permitted;
completed an assignment;
perfected a security interest;
established priority among competing creditors;
confirmed that a receivable has not been financed elsewhere;
confirmed that a token legally represents ownership;
issued a token;
operated a blockchain;
operated a factoring or trade-finance platform;
provided funding;
acted as a custodian;
moved transaction money;
provided stablecoin settlement;
guaranteed payment;
valued the receivable;
recommended financing or investment;
or provided legal, regulatory, banking, factoring, investment, tax, accounting, custody, settlement or valuation advice.

Important: DaDepo provides technology and information tools. It does not provide legal, financial, investment, tax, accounting, banking, factoring, trade-finance, blockchain, token-issuance, custody, settlement, underwriting or valuation advice or services unless a specific service is expressly identified and lawfully provided. Tokenisation does not by itself establish legal ownership, enforceability, priority, transferability or settlement finality. Applicable law and transaction requirements vary by jurisdiction and structure.

A practical pre-tokenisation receivable checklist

Before a trade receivable is represented digitally, financed or transferred, ask:

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?
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?
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?

If the underlying asset is not reliable before tokenisation, tokenisation only gives the uncertainty a better transport layer.

The next generation of tokenisation starts before the token

The most useful part of the POSCO developments is not that a large trading company has experimented with blockchain.

Large companies have tested blockchain for years.

The stronger signal is the workflow.

The August transaction did not begin by minting a digital representation of whatever was in the invoice.

It began by reconciling multiple documents around the receivable.

The July proof of concept did not stop at issuance.

It explored transfer, management, compliance controls and settlement.

Together, the projects point toward a more mature model for real-world assets.

The future is unlikely to be:

PDF
    ->
Token

It is more likely to be:

Economic right
    ->
Evidence
    ->
Reconciliation
    ->
Verified current state
    ->
Ownership and transfer rules
    ->
Digital representation
    ->
Financing
    ->
Settlement
    ->
Lifecycle

The token is important.

But it is the last step in making the asset digital, not the first step in making the asset real.