Invoice Received Amount

Overview

Invoice Received Amount is the amount of the payment asset that the system has actually detected as received for the invoice. Its practical value comes from making the payment lifecycle deterministic for the payer, merchant, support team, and accounting system.

It is derived from independently observed transactions after applying asset precision and attribution rules. Depending on policy, the value may include unconfirmed funds, only accepted funds, or the sum of several transactions. In practice, the system should preserve the original request, the observed blockchain or checkout evidence, and every status change that affects this value. This makes support investigations and financial reconciliation possible without reconstructing the payment from screenshots or mutable client data.

The system should state the confirmation scope, avoid floating-point arithmetic, exclude unrelated transfers, and preserve each contributing transaction so the aggregate can be audited. The implementation should use exact asset precision, authenticated server-side updates, and idempotent processing wherever repeated API calls, blockchain observations, or webhook deliveries can occur.

It differs from requested amount, which is what the invoice asks for, and from settlement amount, which is what the merchant ultimately receives after conversion or fees. It should be interpreted alongside Invoice Requested Amount, Invoice Received Amount, Invoice Settlement Amount. These concepts belong to the same workflow, but each answers a different operational question and should not be collapsed into one ambiguous field.

If an invoice requests 100 USDT and two attributed transfers of 60 and 40 USDT are accepted, the received amount becomes 100 USDT. The practical test is whether a merchant can explain how the value was produced, verify it independently, and apply the same rule consistently when the payment is delayed, duplicated, partially paid, refunded, or reviewed manually.