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.
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.
Start with the question each record answers
An invoice request answers: “What document does the requester say they need, and what details did they provide?” 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.
Payment status answers: “What transaction evidence exists?” 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’s official materials describe electronic invoicing and application/payment functions as separate product surfaces; that separation is operationally important.
Delivery status answers: “What was made available or performed under the agreed scope?” Record the session, access route, participants or recipient list as available, materials, replay state and exceptions. ClassIn’s LTI documentation describes classroom data and reports; it does not say that an invoice request or payment event proves that data exists.
A three-lane ledger
| Lane | Minimum record | Does not close |
|---|---|---|
| Invoice request | requester, requested details, owner, review status | payment or delivery |
| Payment/settlement | verified transaction reference and state | invoice eligibility or service completion |
| Delivery | scope, date, access/material evidence, exceptions | tax treatment or learning outcome |
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 “requested” while payment is “pending” and delivery is “scheduled.” If the buyer only needs a sample document for procurement review, all three lanes may remain open because no transaction or delivery has occurred.
Illustrative scenario
Suppose a procurement contact emails on Monday: “Please send the invoice information for our internal approval.” 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:
- invoice request: received, details under review;
- payment: not evidenced;
- delivery: scheduled, not delivered.
On Friday, the team can add the session and access evidence. If payment later fails or is reversed, that change belongs in the payment lane. It should not erase the delivery record, and delivery should not be backfilled merely because a document was requested.
The counterexample: a document attached to a completed service
Sometimes an approved invoice and a completed session appear together. That is convenient, but correlation is not causation. The operator should still retain the evidence that each event occurred. An invoice may refer to a package of services rather than one session. A delivered workshop may be complimentary or part of a larger contract. Only the underlying agreement and records can establish the intended relationship.
This is why a status such as “closed” needs a reason: closed because invoice request was answered; closed because payment was reconciled; closed because delivery evidence was accepted. One undifferentiated “paid and delivered” label is hard to audit and easy to misread.
What the official pages do and do not say
The Alipay e-invoice page describes an electronic-invoice solution. The Web/mobile application page describes application creation, configuration, review and functions such as payment or login. Neither page determines which entity should issue a particular document to a particular buyer. The ClassIn LTI page describes classroom integrations and data surfaces. It cannot establish that a course was delivered, that a buyer accepted it, or that a provider is qualified to sell it in China.
Do not turn these pages into a promise. Tax classification, invoicing obligations, contract terms and refund rights need the correct commercial facts and specialist review. This article intentionally stops at record separation.
For the procurement-side service boundary, see China Training Procurement Brief: Service, Not Course. For payment and refund sequencing, read Payment Button Is Not Refund Operation. For the user path from access to delivery, see End-to-End Access, Payment and Delivery Test Script.
A review checklist
Before calling an enterprise training order delivered, ask:
- Is the invoice merely requested, drafted, issued or reconciled?
- Is there independent payment or settlement evidence?
- What exact service or session was in scope?
- What access, material or attendance evidence exists?
- Which items are pending, disputed or outside the operator’s authority?
The checklist protects the buyer and the provider. It also gives a later reviewer a clean way to find the missing fact instead of treating an administrative email as a completion certificate.
If you want a scoped review of how your buyer documents, payment flow and delivery evidence should be separated, submit a validation request. The request does not promise tax advice, invoice issuance, eligibility or a commercial result.
Sources and evidence boundary
- Alipay e-Invoice — checked 2026-08-23. Supports an electronic-invoice product surface; does not decide tax treatment or issuance duty.
- Alipay Web/Mobile Application — checked 2026-08-23. Supports distinct application, configuration, review and payment/login functions; does not guarantee access for any entity or region.
- ClassIn LTI — checked 2026-08-23. Supports classroom data and report surfaces; does not prove service completion or acceptance.
Status names that reduce confusion
Use status names that describe the event rather than a hoped-for ending. For the invoice lane, “requested,” “details incomplete,” “under review,” “issued,” and “reconciled” are different states. For payment, “not evidenced,” “pending,” “received,” “reversed,” and “disputed” should not be collapsed. For delivery, “planned,” “access tested,” “performed,” “materials sent,” and “accepted under scope” each require their own evidence.
The point is not to create bureaucracy around a small workshop. It is to prevent a later reader from assuming that an email attachment closed an entire commercial cycle. A spreadsheet with three columns is enough when each column has an owner and a source. A large CRM workflow is not required if the underlying distinctions are clear.
Keep the buyer’s wording where it changes interpretation. “We need an invoice for internal approval” is different from “please invoice the completed training.” The first describes a procurement step; the second is a claim about the buyer’s framing that still needs delivery evidence. Record the difference without deciding which legal document is required.
When a request is outside the team’s authority, escalate it rather than filling the blank. An operator can preserve the request, commercial context and deadline. A tax adviser or authorised finance owner may need to decide what can be issued. This boundary protects the article’s central operational claim: separate records make missing authority visible.
The same rule applies to a purchase order, receipt or approval screenshot. Such documents can be attached to the commercial record, but they should not be used as a substitute for the delivery card. If a buyer asks for a document in order to release an internal approval, that is a step in their process. It may be useful evidence of coordination while remaining silent about whether the service was paid for or performed.
Give each lane a handoff owner. Finance can confirm a transaction without confirming whether the facilitator delivered the workshop. Delivery operations can confirm the session without deciding what document may be issued. The buyer’s procurement contact can confirm that a request is complete for internal review without accepting the service. Recording these handoffs prevents a well-intentioned operator from speaking for a function they do not control.
Use references to connect the lanes, not a single master status. A reference can point from the invoice request to a purchase order, from the payment record to a transaction, and from the delivery record to a session. If one reference is missing, show the gap. The absence is an operational fact and a reason to ask a question, not a reason to fill the gap with an assumption.
The result is a clearer handoff between procurement, finance and delivery, without pretending that one team owns every decision.
It also makes a later reconciliation possible when the request, transaction and session occur weeks apart.
Do not delete the open state merely to make a dashboard look finished.
An honest pending status is more useful than a tidy but unsupported completion label.