The Invoice Exists. The Receivable May Not: What Radiant World Reveals About Trade-Finance Asset Identity

Invoice finance starts with something that looks reassuringly concrete.

An invoice has:

• a seller;
• a buyer;
• an invoice number;
• an issue date;
• a currency;
• an amount;
• a due date;
• payment instructions; and
• usually some description of goods or services.

It looks like an asset.

It can be uploaded.

It can be scanned.

It can be entered into a financing platform.

It can be shown to a lender.

It can even be digitally signed, tokenised or reconciled against another system.

But an invoice document is not the same thing as a current receivable.

That distinction has become unusually visible in the widening disputes around Singapore-based commodity trader Radiant World.

In one Singapore High Court claim, invoice-finance provider Incomlend alleges that it advanced $31.7 million in May 2026 against two invoices issued to Glencore International AG with a combined face value of more than $34 million.

According to reporting on Incomlend’s court filing, the invoices were represented as unpaid amounts due from Glencore.

When Incomlend later approached Glencore for payment in August, the claimant says it was told that the invoices had already been paid and that the underlying contracts were not genuine.

The filing also alleges discrepancies involving payment terms, bank-account details and shipment information.

Bloomberg Law: Radiant World Sent Lender Fake Glencore Deals, Lawsuit Says

The Business Times: Radiant World and its founder sued in Singapore for US$34 million

Radiant World has previously denied wrongdoing and said that it conducts its business to high commercial and legal standards.

The allegations have not been finally adjudicated.

Separately, the legal and financing pressure around the group has become much larger.

A Jefferies-linked fund, LAM Trade Finance Group II, obtained a freezing order from London’s High Court against Radiant World, its founder Pinkesh Nahar, Sapphire Minmetals and its chairman Rakesh Sethi. Reuters reported on 5 September that the fund had nearly $500 million of exposure to Radiant World, Nahar and another entity, while the Financial Times reported a freezing order of up to $499 million.

Reuters: Jefferies-linked fund secures freezing order against trader Radiant World

Reuters: Jefferies-linked fund has almost $500 million exposure to trader Radiant World

Those proceedings should not be collapsed into one transaction.

The Incomlend financing and the Jefferies-linked exposure are different.

The legal claims are different.

The documents are different.

The counterparties and financing structures may be different.

But they point toward the same infrastructure question:

What evidence is required before an invoice can safely be treated as a current, owned and financeable receivable?

The answer is much more than the invoice itself.

An invoice is evidence of a claim—not the claim in its entirety

A commercial invoice usually records what the seller says is payable.

That is useful evidence.

It does not independently prove every fact required for financing.

A simplified trade chain might look like:

Purchase agreement / purchase order
    ->
Goods or services supplied
    ->
Delivery / performance
    ->
Buyer obligation arises
    ->
Invoice issued
    ->
Receivable outstanding
    ->
Payment

The invoice sits inside that chain.

It is not the whole chain.

A financier may need evidence that:

• the relevant seller exists;
• the buyer exists;
• the underlying transaction exists;
• goods or services were actually supplied;
• the invoice corresponds to that transaction;
• the buyer is the correct obligor;
• the amount is correct;
• the amount has not been adjusted;
• the receivable remains unpaid;
• the seller still owns it;
• it has not already been assigned or pledged elsewhere;
• payment has not already been redirected;
• there is no material dispute or set-off; and
• the financing documents create the intended rights.

The existence of a PDF cannot answer all of those questions.

The invoice can be genuine while the receivable is no longer outstanding

The most important lesson from the Incomlend allegations is not necessarily document forgery.

It is the alleged payment-state mismatch.

Suppose a supplier issues a genuine invoice:

Invoice 123
Face amount: $20m
Buyer: Company B
Due date: 30 June

The buyer then pays the supplier on 15 June.

The invoice document does not cease to exist.

Its number remains valid.

Its historical face amount remains $20 million.

The underlying trade may have been completely genuine.

But on 16 June:

Current receivable balance = $0

A lender shown only the original invoice could therefore see a perfectly authentic historical document describing an obligation that is no longer outstanding.

That is why:

Invoice amount

is not the same field as:

Current outstanding amount

The second field needs a date and evidence.

Payment is an asset-state transition

Receivables are not static.

They move through states.

A simple lifecycle might be:

Created
    ->
Issued
    ->
Accepted / acknowledged
    ->
Outstanding
    ->
Partially paid
    ->
Paid

Alternative paths can include:

Outstanding
    ->
Disputed
    ->
Credit note
    ->
Adjusted balance

or:

Outstanding
    ->
Assigned
    ->
Paid to assignee

or:

Outstanding
    ->
Overdue
    ->
Default
    ->
Collection / restructuring

A financing system that stores only:

Invoice status: Issued

may know almost nothing about the current asset.

The relevant question is:

What is the payment right now?

Face value is not current balance

An invoice can start at $10 million.

Then:

• $2 million is paid;
• $500,000 is credited;
• $250,000 is disputed;
• $100,000 is subject to a contractual deduction.

The historical invoice still says:

$10,000,000

The current economic position may be:

Original invoice             $10,000,000
Less cash received           $2,000,000
Less credit note               $500,000
Disputed amount                $250,000
Other adjustment               $100,000
----------------------------------------
Nominal remaining balance    $7,150,000

Even that does not necessarily equal the financeable amount.

The financing agreement may apply reserves, concentration limits or advance rates.

Several values therefore need to remain distinct:

Original invoice amount
Current outstanding balance
Eligible financed balance
Advance amount
Current lender exposure
Expected recovery

A system with one field called:

Amount

cannot represent this safely.

The underlying trade is another object

An invoice usually derives from something.

For physical commodities that may include:

• master sale agreement;
• trade confirmation;
• purchase order;
• cargo nomination;
• shipment;
• bill of lading;
• warehouse document;
• inspection certificate;
• delivery record;
• title transfer;
• price calculation;
• final invoice; and
• payment.

For services it may instead involve:

• service agreement;
• statement of work;
• milestones;
• timesheets;
• acceptance;
• completion certificate; and
• invoice.

For manufactured goods:

• purchase order;
• production;
• shipment;
• delivery;
• quality acceptance;
• returns; and
• invoice.

The receivable is therefore connected to a performance history.

The document graph matters.

A strong invoice package should be internally coherent

Consider a commodity financing package.

The documents may say:

Invoice:
Cargo A
$18.4m
Vessel Alpha
Payment account X

But another source says:

Shipment record:
Cargo A
Vessel Beta

or:

Underlying contract:
Payment account Y

or:

Buyer ledger:
Invoice already settled

Those differences do not automatically prove fraud.

There may be legitimate amendments, operational substitutions, document corrections or settlement arrangements.

But they are exactly the kinds of discrepancies that should stop the asset from being treated as unquestioned.

The correct system response is:

Mismatch detected
    ->
Source identified
    ->
Review required

not:

Invoice PDF received
    ->
Asset verified

Buyer confirmation has a different evidential role from seller documents

Most of the documents in an invoice-finance package may originate from the seller.

That creates an obvious concentration of evidence.

A seller can provide:

• invoice;
• contract copy;
• delivery record;
• account statement;
• bank details;
• payment instructions; and
• declarations about the balance.

Those documents can be genuine copies and still fail to establish the buyer’s current position.

A buyer or debtor confirmation can answer a different question:

Does the obligor recognise this obligation?

Depending on the structure and legal context, confirmation may cover:

• invoice reference;
• amount;
• currency;
• due date;
• delivery acceptance;
• dispute status;
• current balance;
• payment status;
• payment account; and
• notice of assignment.

Buyer confirmation is not magical.

It can itself be incomplete, mistaken, stale or unauthorised.

But it adds an independent evidence source.

Confirmation needs identity and authority

A message that says:

Yes, invoice is valid.

is only useful if the reviewer knows:

• who sent it;
• which legal entity they represent;
• whether they are authorised;
• which communication channel was used;
• whether the address or account was independently verified;
• which exact invoice was confirmed;
• what exactly was confirmed; and
• when the confirmation occurred.

A confirmation from:

[email protected]

cannot safely be treated the same as a verified response through an established buyer channel.

The confirmation itself therefore needs provenance.

“Buyer confirmed” should not be one checkbox

A useful confirmation record could distinguish:

Invoice existence confirmed
Goods received confirmed
Amount confirmed
No dispute confirmed
Outstanding balance confirmed
Assignment notice acknowledged
Payment instructions confirmed

These are not identical statements.

A buyer can say:

Yes, we bought the goods.

while also saying:

But we already paid the invoice.

The underlying trade may therefore be real while the financeable receivable is gone.

That distinction is central to the Radiant World / Incomlend allegations as publicly reported.

Ownership is separate from existence

Even an authentic and unpaid receivable may not belong to the party offering it for financing.

The receivable may already have been:

• sold;
• factored;
• assigned;
• pledged;
• participated;
• securitised;
• transferred into an SPV;
• subjected to a floating charge;
• included in another borrowing base; or
• otherwise encumbered.

The financier therefore needs to answer:

Does the receivable exist?

and separately:

Who owns it?

and separately:

Who has security or economic rights over it?

These questions can have different answers.

One receivable can support several economic relationships

Suppose Supplier A has a $5 million receivable against Buyer B.

Supplier A may:

1. remain legal owner;
2. grant Lender X security over receivables;
3. sell a participation in the economics to Fund Y;
4. appoint Servicer Z to collect;
5. direct Buyer B to pay a controlled account.

The asset map becomes:

Receivable
    ->
Legal owner: Supplier A
    ->
Secured party: Lender X
    ->
Economic participant: Fund Y
    ->
Servicer: Servicer Z
    ->
Payment account: Controlled Account

A simple field called:

Owner: Supplier A

does not reveal the whole financing state.

Duplicate financing is a relationship problem

The classic fear in invoice finance is that the same receivable is financed twice.

A simplified example:

Receivable R-100
    ->
Pledged to Lender A

Then the same invoice is presented to:

Lender B

If neither lender sees the other relationship, both can believe they have financed the same payment right.

But duplicate-financing detection is not merely document hashing.

Two PDFs can differ visually while representing the same underlying receivable.

Conversely, one invoice can legitimately generate multiple financing interests in a structured transaction.

The key object is the receivable identity.

A useful duplicate check may need to combine:

• seller;
• buyer;
• invoice number;
• purchase-order reference;
• invoice date;
• amount;
• currency;
• shipment reference;
• underlying contract;
• due date;
• assignment history; and
• financing relationships.

The question is not:

Have we seen this PDF before?

It is:

Have we seen this payment right before?

A receivable needs a durable identity

The identity of a receivable should survive document replacement.

Suppose an invoice is corrected.

Version 1:

Invoice 2026-481
$12.5m

Version 2:

Invoice 2026-481
$12.3m

The first file may be superseded.

The underlying receivable relationship continues.

A durable record should preserve:

Receivable ID
    ->
Invoice v1
    ->
Correction
    ->
Invoice v2

not create two unrelated assets.

Payment-account changes are high-risk state changes

Invoice finance often depends on where the debtor will pay.

Bank-account information can appear in:

• invoice;
• assignment notice;
• factoring notice;
• servicing letter;
• email amendment;
• settlement instruction; or
• buyer portal.

A change from:

Account A

to:

Account B

can be completely legitimate.

It can also be critical.

A robust record should preserve:

• previous account;
• new account;
• effective date;
• reason;
• source;
• approver;
• buyer acknowledgement where relevant;
• financier approval where required; and
• superseded instruction.

The system should not silently overwrite the old bank details.

The payment event needs external evidence

A receivable cannot safely remain “outstanding” forever merely because nobody updated the finance platform.

Payment can be evidenced by different sources:

• debtor statement;
• bank transaction;
• controlled-account receipt;
• servicer record;
• reconciliation file;
• remittance advice;
• ERP ledger;
• payment-service confirmation; or
• another authoritative source defined by the transaction.

Each source has different reliability.

The record should therefore answer:

Payment claimed?
Payment observed?
Payment reconciled?
Payment final?
Applied to which receivable?
As of when?
According to which source?

This is especially important where one cash receipt covers multiple invoices.

Cash allocation is part of receivable state

A buyer may pay:

$20m

against an account containing:

Invoice A: $7m
Invoice B: $8m
Invoice C: $9m

The payment does not by itself say which invoices are extinguished.

The allocation may follow:

• remittance advice;
• contractual rules;
• debtor designation;
• creditor allocation;
• automated reconciliation; or
• later manual correction.

A receivable can therefore remain apparently outstanding because the cash exists but has not yet been allocated correctly.

This is another reason to distinguish:

Cash received

from:

Receivable settled

Credit notes can change the asset without changing the original invoice

A buyer may return goods.

A seller may grant a rebate.

Quantity may be adjusted.

Quality may be disputed.

A pricing formula may be recalculated.

The original invoice may remain intact in the archive.

But a credit note changes the receivable.

A lifecycle might look like:

Invoice issued: $10m
    ->
Credit note: $1m
    ->
Current gross receivable: $9m

If the financier sees only the original invoice, the asset is overstated.

Disputes need their own state

A disputed receivable is not the same as a paid receivable.

It is not the same as an undisputed performing receivable either.

A dispute record may need:

• disputed amount;
• undisputed amount;
• reason;
• opening date;
• parties;
• supporting evidence;
• contractual process;
• current status;
• resolution;
• credit note;
• settlement; and
• effective date.

The financeable balance may change while the dispute remains open.

The commodity-trade context makes document relationships especially important

Commodity trading often combines:

• high transaction values;
• fast movement;
• multiple legal entities;
• short financing cycles;
• physical cargo;
• hedging;
• letters of credit;
• bilateral credit;
• inventory finance;
• receivables finance;
• title documents;
• shipping documents; and
• multiple banks or funds.

That creates many legitimate documents.

It also creates many places where one transaction can be misunderstood.

Radiant World is a particularly large example.

Reuters reported in August that the company had 21 creditors with registered claims over its assets, more than double the number before the start of 2025.

Reuters: Claims against Radiant World assets have doubled since 2025, filings show

The point is not that the existence of multiple creditors implies wrongdoing.

It does not.

The point is that once many financing relationships coexist around one trading group, asset identity and encumbrance become harder to manage from isolated deal files.

Company-level credit exposure is not the same as receivable-level exposure

A lender may say:

Exposure to Radiant World: $100m

That is a useful portfolio number.

It does not identify:

• which legal entity owes the money;
• which invoices support it;
• which buyers are expected to pay;
• which receivables remain outstanding;
• which assets secure the facility;
• which receivables have been assigned;
• which payments have been received;
• which claims are disputed; or
• which other lenders may have competing interests.

A group-level exposure needs an asset-level map underneath it.

Legal-entity identity matters

Large trading groups can contain:

• operating companies;
• holding companies;
• financing vehicles;
• affiliates;
• joint ventures;
• SPVs; and
• entities with historic relationships that may no longer reflect current control.

A document saying:

Radiant World

is not precise enough for a legal asset record.

A receivable record should identify the actual seller entity.

It should identify the actual buyer entity.

It should identify the financing entity.

It should identify any assignor, assignee, security provider or servicer separately.

An invoice can be authentic but attached to the wrong legal entity

Imagine:

Seller:
ABC Trading Singapore Pte Ltd

But the financing agreement is signed by:

ABC Trading Holdings Ltd

Perhaps the holding company has authority.

Perhaps there is an assignment.

Perhaps there is a guarantee.

Perhaps there is not.

The system cannot infer the legal relationship from the shared brand name.

Entity precision matters.

The financing document is another layer

Even if the receivable is valid, unpaid and owned by the seller, the financier still needs its own rights.

Those can arise through:

• outright assignment;
• factoring;
• security assignment;
• charge;
• pledge;
• trust;
• participation;
• borrowing-base facility;
• receivables purchase agreement; or
• another financing structure.

The Asset Passport should distinguish:

Underlying receivable

from:

Financing contract

The financier’s rights come from the second object interacting with the first.

Notice of assignment is a state transition

In some structures, the debtor is notified that the receivable has been assigned.

That event can affect:

• payment instructions;
• discharge mechanics;
• set-off;
• perfection;
• priority;
• servicing;
• confidentiality; and
• enforcement.

The exact legal effects depend on jurisdiction and contract.

From an infrastructure perspective, notice should be an event:

Assignment created
    ->
Notice prepared
    ->
Notice delivered
    ->
Delivery evidence
    ->
Debtor acknowledgement where applicable

not just:

Assigned: Yes

Priority cannot be inferred from upload order

If two financiers claim rights over the same receivable, the fact that one uploaded its document first to a platform means nothing about legal priority.

Priority can depend on:

• governing law;
• transaction structure;
• assignment timing;
• notice;
• registration;
• perfection;
• contractual subordination;
• possession or control where relevant;
• insolvency rules; and
• other legal factors.

DaDepo can preserve the evidence.

It should not invent the legal conclusion.

A financing platform needs to know what it does not know

This is perhaps the most important design principle.

A system should distinguish:

Invoice uploaded

from:

Invoice fields extracted

from:

Underlying documents linked

from:

Buyer confirmation received

from:

Payment state confirmed

from:

Ownership reviewed

from:

Financing state reviewed

Those states represent different levels of evidence.

The first should never silently become the last.

Provenance matters more when documents conflict

Suppose the system sees two statements:

Seller:
Invoice remains unpaid.

and:

Buyer:
Invoice was paid on 12 May.

The system should not choose one and overwrite the other.

It should preserve:

Statement A
Source: Seller
Date: ...

Statement B
Source: Buyer
Date: ...

Then require reconciliation.

This is exactly the type of problem where provenance is more valuable than a single “truth” field.

Current state needs an as-of date

Receivables change quickly.

A statement can be accurate on Monday and wrong on Friday.

Therefore:

Outstanding: Yes

is incomplete.

The system needs:

Outstanding balance: $4.2m
As of: 5 September 2026 10:00 UTC
Source: Servicer reconciliation

or another clearly identified source.

Time is part of the state.

“Verified” needs scope

A platform may describe an invoice as verified.

That word can mean many things.

It may mean:

• file integrity checked;
• seller identity checked;
• buyer identity checked;
• invoice number matched;
• duplicate-document check passed;
• purchase order matched;
• delivery evidence found;
• debtor confirmation received;
• outstanding balance confirmed;
• bank account verified;
• ownership reviewed;
• assignment reviewed; or
• payment status reconciled.

Those are different checks.

A useful record should say:

Who checked what
Against which source
On what date
With what result
And with what limitations

The label:

Verified invoice

is too broad.

The Radiant World allegations expose three separate failure modes

The publicly reported Incomlend allegations are useful because they illustrate several distinct problems at once.

1. Underlying-transaction problem

The claimant says Glencore told it that underlying contracts were not genuine.

That goes to the source transaction.

2. Payment-state problem

The claimant says Glencore told it that the invoices had already been paid.

That goes to the current receivable balance.

3. Document-consistency problem

The court filing reportedly identifies discrepancies in payment terms, bank details and shipment information.

That goes to reconciliation and provenance.

Even if one of these checks succeeds, another can fail.

That is why invoice finance cannot rely on one verification step.

The strongest control is a linked evidence graph

A receivable can be represented as a graph:

Seller
    ->
Underlying contract
    ->
Purchase order / trade confirmation
    ->
Shipment / performance
    ->
Invoice
    ->
Buyer obligation
    ->
Current balance
    ->
Ownership / assignment
    ->
Financing
    ->
Payment account
    ->
Payment events

Each node has evidence.

Each relationship can change.

That is much stronger than a folder containing:

invoice.pdf
contract.pdf
shipping.pdf

A receivable Asset Passport should preserve the whole lifecycle

For DaDepo, this is a strong example of why a receivable should be treated as a structured, time-aware asset rather than a document type.

Asset identity

• internal receivable ID;
• seller legal entity;
• buyer legal entity;
• invoice number;
• invoice date;
• currency;
• original face amount;
• due date;
• purchase-order or contract reference;
• shipment or performance reference;
• jurisdiction;
• governing law where relevant; and
• current lifecycle state.

Underlying transaction

• master agreement;
• purchase order;
• trade confirmation;
• goods or services description;
• quantity;
• price basis;
• delivery terms;
• shipment;
• vessel or transport reference where relevant;
• delivery evidence;
• acceptance;
• inspection;
• title evidence where relevant; and
• amendments.

Invoice record

• invoice document;
• invoice version;
• issue date;
• amount;
• currency;
• due date;
• payment terms;
• bank details;
• tax treatment where relevant;
• corrections;
• replacement invoices;
• credit notes; and
• superseded versions.

Current balance

• original amount;
• payments received;
• payment dates;
• partial payments;
• credit notes;
• deductions;
• disputes;
• set-off;
• remaining balance;
• balance source;
• reconciliation status; and
• as-of timestamp.

Buyer confirmation

• confirmation request;
• recipient;
• verified buyer identity;
• authority;
• communication channel;
• invoice confirmed;
• amount confirmed;
• balance confirmed;
• dispute status;
• payment status;
• assignment acknowledged where relevant;
• bank details confirmed where relevant; and
• confirmation timestamp.

Ownership

• original creditor;
• current legal owner;
• assignment;
• assignee;
• transfer date;
• retained interest;
• participation;
• trust relationship;
• security interest;
• financing vehicle;
• servicer; and
• current entitlement.

Financing

• financier;
• financing agreement;
• structure;
• commitment;
• advance;
• advance rate;
• eligible balance;
• financed amount;
• borrowing-base inclusion;
• security;
• concentration treatment;
• recourse;
• repayment;
• current exposure; and
• release.

Duplicate / competing-interest review

• same receivable detected elsewhere;
• similar invoice number;
• same buyer;
• same seller;
• same shipment;
• same contract;
• same amount;
• prior assignment;
• prior pledge;
• existing charge;
• other financing relationship;
• reviewer; and
• resolution.

Payment

• expected payer;
• expected account;
• remittance advice;
• bank or provider reference;
• cash receipt;
• receipt timestamp;
• allocation;
• reconciliation;
• shortfall;
• overpayment;
• payment reversal;
• return;
• final settlement state; and
• source.

Dispute and adjustment

• dispute opening date;
• disputed amount;
• reason;
• buyer position;
• seller position;
• evidence;
• credit note;
• negotiated adjustment;
• resolution;
• resolved balance; and
• close date.

Provenance

• source document;
• source system;
• seller-provided evidence;
• buyer-provided evidence;
• financier record;
• bank or payment record;
• servicer source;
• registry source;
• AI-extracted field;
• user-confirmed field;
• professional review;
• effective date;
• version; and
• last updated timestamp.

This turns an invoice package into a traceable receivable record.

The record should preserve failed checks

If a buyer confirmation fails, that is useful information.

If the buyer cannot identify the invoice, that matters.

If the amount differs, that matters.

If the payment account differs, that matters.

If the invoice was already paid, that matters.

The system should not simply remove the asset and discard the evidence.

It should record:

Check performed
Result
Source
Date
Exception
Resolution

Failed checks are part of the asset history.

Historical truth and current truth should coexist

A paid invoice can still have historical value.

The record may need to show:

Invoice issued: 1 May
Outstanding: $34m
Payment received: 20 May
Current balance: $0

The statement:

Invoice amount = $34m

remains historically true.

The statement:

Receivable outstanding = $34m

is no longer true.

Good asset infrastructure keeps both.

This matters for tokenisation too

Putting an invoice or receivable on-chain does not solve the state problem.

A token can represent:

Invoice 123

very reliably.

But if Invoice 123 was paid yesterday and the token still represents the original face value today, the ledger has preserved stale information perfectly.

The same is true for:

• digital registries;
• blockchain;
• data rooms;
• securitisation platforms;
• marketplaces; and
• AI extraction.

Better technology does not remove the need for current external evidence.

It makes the quality of the state model more important.

This matters for AI-assisted review

Invoices are attractive AI documents.

They are structured.

They contain repeated fields.

AI can extract:

• invoice number;
• seller;
• buyer;
• amount;
• currency;
• dates;
• payment terms;
• purchase-order reference;
• bank details; and
• line items.

Across a document package, AI can also help identify:

• inconsistent buyer names;
• conflicting amounts;
• different payment terms;
• duplicate invoice references;
• conflicting bank details;
• missing contracts;
• mismatched shipment references;
• absent delivery evidence;
• credit notes not reflected in balances;
• payments not reflected in current state;
• multiple assignments;
• missing buyer confirmations; and
• stale status dates.

That is useful.

AI should not independently conclude:

• that the underlying trade occurred;
• that a contract is genuine;
• that goods were delivered;
• that the buyer accepted them;
• that an invoice is enforceable;
• that the receivable remains unpaid;
• that the seller still owns it;
• that no other financier has rights over it;
• that a bank account is controlled by the correct party;
• that an assignment is legally effective;
• that priority is established;
• that an alleged discrepancy proves fraud;
• that a buyer confirmation is legally sufficient; or
• that the receivable is suitable for financing.

Those are questions of external evidence, legal effect, credit and professional judgment.

What DaDepo can contribute

DaDepo does not need to become an invoice-finance lender.

It does not need to decide whether a receivable is creditworthy.

The useful role is information infrastructure.

DaDepo can help organise the relationship:

Invoice
    ->
Underlying transaction
    ->
Buyer
    ->
Current balance
    ->
Ownership
    ->
Financing
    ->
Payment evidence
    ->
Current state

That can make several important questions visible before a reviewer relies on the asset.

For example:

• Is the invoice linked to the underlying contract?
• Is shipment or performance evidence available?
• Has the buyer been identified correctly?
• Has the current outstanding amount been updated?
• Are credit notes reflected?
• Has the receivable already been financed?
• Is there another assignment or security interest in the file?
• Have payment instructions changed?
• Is there independent payment evidence?
• Are conflicting statements preserved with provenance?
• When was the asset state last confirmed?

The objective is not:

DaDepo says the receivable is valid.

The better objective is:

The evidence, relationships, current state and unresolved questions are visible enough for an authorised reviewer to assess.

What DaDepo does—and does not do

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

• authenticated every invoice;
• established that the underlying contract is genuine;
• confirmed that goods or services were supplied;
• confirmed delivery or acceptance;
• established that the debtor legally owes the amount;
• confirmed the current balance;
• confirmed that the invoice remains unpaid;
• independently contacted or verified the buyer;
• authenticated a buyer confirmation;
• confirmed ownership of the receivable;
• confirmed that the receivable has not been assigned or pledged elsewhere;
• established legal priority;
• perfected a security interest;
• confirmed bank-account ownership;
• monitored a bank account;
• guaranteed payment;
• provided factoring or invoice discounting;
• provided a lending decision;
• performed underwriting;
• investigated suspected fraud;
• determined that a discrepancy constitutes fraud;
• provided trade finance;
• provided legal advice;
• provided valuation;
• provided credit ratings;
• guaranteed recovery; or
• determined investor suitability.

Important: DaDepo provides technology and information tools. It does not provide legal, financial, banking, factoring, trade-finance, investigation, underwriting, valuation, investment or credit advice or services unless a specific service is expressly identified and lawfully provided. The existence, enforceability, ownership, transferability, priority and payment status of a receivable depend on the relevant transaction, evidence, governing documents, external records and applicable law.

A practical receivable-state checklist

Before an invoice is treated as a financeable receivable, ask:

1. Seller: Which exact legal entity issued the invoice?
2. Buyer: Which exact legal entity is expected to pay?
3. Underlying transaction: Which contract, purchase order or trade confirmation created the obligation?
4. Performance: What evidence supports shipment, delivery, service completion or other performance?
5. Invoice: What is the exact invoice number, amount, currency and date?
6. Version: Has the invoice been amended, replaced or corrected?
7. Buyer recognition: Does the buyer recognise the transaction and invoice where confirmation is part of the process?
8. Current balance: What remains outstanding today?
9. As-of date: When was that balance last confirmed?
10. Payment: Has any amount already been paid?
11. Allocation: Has received cash been correctly allocated to the invoice?
12. Adjustments: Are credit notes, returns, rebates, discounts and set-offs reflected?
13. Dispute: Is any part of the amount disputed?
14. Ownership: Who currently owns the receivable?
15. Assignment: Has it been sold, assigned, participated or transferred?
16. Security: Has it been pledged or charged to another financier?
17. Duplicate financing: Does the same payment right appear in another financing package?
18. Notice: Has the buyer received any assignment or payment-direction notice required by the structure?
19. Payment account: Which account should receive the payment, and what supports that instruction?
20. Account change: Have any bank details changed since origination?
21. Financing: Which financier has advanced against the receivable and how much?
22. Current exposure: What financing remains outstanding against it?
23. Provenance: Can each material field be traced to a source?
24. Conflict: Are contradictory seller, buyer, bank or servicer records visible rather than overwritten?
25. Review: Which checks remain unresolved?

If the answer to “does this payment right exist, who owns it, and how much is still payable now?” is unclear, the asset is not ready to be treated as a reliable receivable.

The lesson is bigger than Radiant World

Commodity finance has seen document disputes before.

Invoice finance has seen duplicate financing before.

Banks have financed receivables that later became disputed, paid, assigned or difficult to collect before.

The Radiant World developments matter because they bring several of those risks together at institutional scale.

The market can have:

• major counterparties;
• sophisticated lenders;
• large funds;
• established trading relationships;
• expensive legal documentation; and
• professionally produced transaction files.

The core asset question can still remain unresolved.

That question is not:

Do we have an invoice?

It is:

What payment right exists now?

The distinction is fundamental.

An invoice may be genuine.

The trade may be genuine.

The buyer may be genuine.

The receivable may have existed.

And yet the current balance may be zero.

Or the receivable may belong to somebody else.

Or another financier may already have rights over it.

Or the transaction may be disputed.

Or the documents may not describe the same trade at all.

That leads to a broader rule for private-asset infrastructure:

A document can prove that something was recorded. A financeable asset requires evidence of what right exists now.

For receivables, the current state matters as much as the original invoice.

That is why the asset needs an identity, a lifecycle and provenance—not just a PDF.

Further reading

• Bloomberg Law: Radiant World Sent Lender Fake Glencore Deals, Lawsuit Says
• The Business Times: Radiant World and its founder sued in Singapore for US$34 million
• Reuters: Jefferies-linked fund secures freezing order against trader Radiant World
• Reuters: Jefferies-linked fund has almost $500 million exposure to trader Radiant World
• Reuters: Claims against Radiant World assets have doubled since 2025, filings show
• Reuters: Mizuho Bank files case against Radiant World in Singapore
• Singapore Court of Appeal: UniCredit Bank AG v Glencore Singapore Pte Ltd [2023] SGCA 41