Buying for work: invoices and what can be issued

Vendor receipts go to the account, not to a card. Understand that before you file an expense.

Anyone who uses an AI subscription for work and wants to expense it hits the same wall: there is nothing that looks like a tax invoice. Here is exactly what exists, what does not, and how to make the paperwork land.

What the vendor gives you

The account's billing page generates an invoice or receipt with the amount, the date, the plan name and a billing reference. That document is issued to the account, not to a card and not to your company's legal name — which shapes every conversation that follows.

For most finance departments this is enough: it shows the service was bought and the money moved. It does not contain a tax ID or your company name — if you need those, the vendor channel generally cannot provide them. Ask finance that question first, not the seller.

What we can give you

Proof of payment, two forms: the on-chain transaction hash, or the order number. They prove the money moved, to which address and at what time, but they are technical evidence, not a tax invoice. A hash is verifiable by anyone in a public block explorer, which carries more weight with an auditor than a screenshot does.

No email is sent from this shop; there is no mail system behind an order. So do not promise finance that you will "forward the confirmation" — that email will not exist. What you hand over is the order number and the on-chain proof.

If your internal approval needs a document stating amount, date and purpose, ask before paying — message @cdkstorebot, in English or Chinese, and we will say how far we can actually go. Requirements differ by jurisdiction, and asking first is far easier than fixing it afterwards.

Why a "proper invoice" cannot be issued

A reseller is not an authorised distributor, so there is no invoicing entity behind it. Any reseller claiming to produce a vendor-branded invoice is almost certainly fabricating a document — and the exposure of filing that document lands on the person who submits it, not the one who sold it. That sentence is worth forwarding to finance verbatim.

Three things to do before filing an expense

1. Download the vendor receipt from the account's billing page as a PDF, with date and plan name legible
2. Archive the transaction hash or order number, ideally with the public explorer query alongside it
3. Ask finance in advance whether receipt plus on-chain proof is acceptable, and above what amount extra approval is needed

If your company insists on a formal invoice

Then this path does not work, and forcing it is a bad idea. Two fallbacks: subscribe directly with a company card if the card clears, or have procurement buy official seats. A reseller solves "the card does not work", not "the paperwork does not exist" — and mixing the two questions is how the expense gets rejected.

Extra care when buying for several people

The rules do not change, but mistakes multiply. One invoice carries one network and one exact amount; do not merge several orders into one transfer, because that clears none of them and creates one movement no order can claim. Pay per order, and supply one Organization ID per seat — the value beginning org_ from Settings, then Account. No password, no 2FA code, no recovery code is wanted at any point in the process.

What is refundable and on what arithmetic is on the refund page; how payment works is in the USDT guide; keeping on-chain proof as an accounting record is covered in crypto receipts and records.

Common questions

Back to plans →