{"id":302,"date":"2026-09-10T07:30:00","date_gmt":"2026-09-09T23:30:00","guid":{"rendered":"https:\/\/oribridge.org\/blog\/?p=302"},"modified":"2026-09-08T09:37:01","modified_gmt":"2026-09-08T01:37:01","slug":"invoice-request-not-training-delivery-proof-china","status":"publish","type":"post","link":"https:\/\/oribridge.org\/blog\/invoice-request-not-training-delivery-proof-china\/","title":{"rendered":"An Invoice Request Is Not Proof That Training Was Delivered"},"content":{"rendered":"

An enterprise buyer may ask for an invoice before a purchase is complete. That request is an administrative event. It is not payment confirmation, and it is not evidence that a workshop took place. The three events often appear in one email thread, which makes them easy to collapse into a single status. That is exactly when a delivery ledger becomes unreliable.<\/p>\n

The safe operating answer is simple: keep the invoice request, payment or settlement state, and delivery record as separate objects. Link them with a reference, but do not let one automatically complete the others.<\/p>\n

Start with the question each record answers<\/h2>\n

An invoice request answers: \u201cWhat document does the requester say they need, and what details did they provide?\u201d Record the requester, date, requested document type, billing details supplied, and who must review the request. Do not write that an invoice has been issued unless there is an actual issuance record.<\/p>\n

Payment status answers: \u201cWhat transaction evidence exists?\u201d Record a payment reference, amount and currency only when supported by the relevant system or financial record. A screenshot of a request or a promise to pay is not settlement evidence. Alipay\u2019s official materials describe electronic invoicing and application\/payment functions as separate product surfaces; that separation is operationally important.<\/p>\n

Delivery status answers: \u201cWhat was made available or performed under the agreed scope?\u201d Record the session, access route, participants or recipient list as available, materials, replay state and exceptions. ClassIn\u2019s LTI documentation describes classroom data and reports; it does not say that an invoice request or payment event proves that data exists.<\/p>\n

A three-lane ledger<\/h2>\n
\n\n\n\n\n\n\n\n
Lane<\/th>\nMinimum record<\/th>\nDoes not close<\/th>\n<\/tr>\n<\/thead>\n
Invoice request<\/td>\nrequester, requested details, owner, review status<\/td>\npayment or delivery<\/td>\n<\/tr>\n
Payment\/settlement<\/td>\nverified transaction reference and state<\/td>\ninvoice eligibility or service completion<\/td>\n<\/tr>\n
Delivery<\/td>\nscope, date, access\/material evidence, exceptions<\/td>\ntax treatment or learning outcome<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

This structure is not a tax opinion. It is a control against accidental overstatement. If a buyer requests an invoice before the training date, the invoice lane may be \u201crequested\u201d while payment is \u201cpending\u201d and delivery is \u201cscheduled.\u201d If the buyer only needs a sample document for procurement review, all three lanes may remain open because no transaction or delivery has occurred.<\/p>\n

Illustrative scenario<\/h2>\n

Suppose a procurement contact emails on Monday: \u201cPlease send the invoice information for our internal approval.\u201d The operator records the request and asks which fields must be supplied. No money has been verified. The workshop is scheduled for the following Friday. The ledger should read:<\/p>\n