The E-Invoice That Is Only Prepared: ESF, the Operator and the AI
In Uzbekistan an invoice is not only a PDF with a stamp. The document that carries weight in the e-invoice circuit is the ESF: it is created at an ESF operator and signed with an electronic signature. Firmspace takes a narrower role on purpose. It prepares the data, checks whether the invoice is complete, keeps the issued and received registers, and leaves the creation and signature where the law puts them.
The registers live in Finance as a separate ESF view, and only for a firm working in the Uzbek market. Two tabs: issued and received. A period switch offers month, quarter or year. The issued table shows number, date, customer, STIR, net, VAT and gross in soums; the received table keeps the document currency. A CSV export gives the operator's cabinet the same rows in a form it can reconcile. The screen also says, in plain words, that the PDF from the CRM and the CSV are not an ESF.
Before anything goes to the operator, the invoice is checked against the fields an ESF needs. On the seller side: legal name, address, STIR or JShShIR, VAT payer status and VAT code, bank, MFO and settlement account. On the buyer side: name and STIR, with the address as a warning. On the lines: a name, a unit of measure, a quantity above zero, a price and a VAT rate. Then the supply date, a linked contract or order as the basis of delivery, and the director and chief accountant who sign.
The check separates errors from warnings, and the difference matters. An error means the data set is not ready: no buyer STIR, no unit, a zero quantity, a missing VAT rate, a seller bank account that was never filled in. A warning means the ESF can be prepared but a person should look: the buyer's address is empty, no contract or order is linked, the supply date is missing and the issue date would be used, the firm is not marked as a VAT payer, or the signer names are absent. The screen counts both and shows each issue in the list.
Currency is a separate trap. An ESF is issued in soums, so a foreign-currency invoice needs a Central Bank rate snapshot. Firmspace stores the rate with the invoice; if it is missing, the check reports an error and the totals cannot be converted. With the rate, net, VAT and gross are shown in soums next to the document currency. This is arithmetic, not a guess: no rate, no converted total.
The status of the ESF is a human mark, not an automatic transition. The choices are not issued, data prepared, sent to the operator, confirmed and cancelled. The mark can be set only on an issued invoice, not on a draft or a cancelled one; sent and confirmed require an ESF number. The mark sends nothing, changes no invoice line and adds no tax. It records what a person did at the operator, with the operator name and the date, and the change goes into the audit log.
The issued register is built from invoices and credit notes, excluding drafts and cancelled documents; a credit note is negative. It totals net, VAT and gross in soums and counts two kinds of unfinished work: rows that are not ready because errors remain, and rows that are ready but not yet issued at the operator. That second count is the one a finance lead checks on a Monday: the invoice exists, the client has it, but the ESF has not been registered yet.
The received register starts from expenses, not from a separate inbox. Each expense can carry the supplier's ESF number, date and STIR. Where the number is present, the row is marked; where it is absent, the summary shows the input VAT that currently has no ESF behind it. The software does not decide whether that VAT is deductible. It shows the amount and the gap, and the accountant decides. That is the honest division: the CRM can count, the accountant can judge.
The AI assistant can prepare the invoice that feeds this process, but it cannot certify the result. It creates a draft invoice from a customer name and line items, applies the firm's tax policy, and can send the invoice or mark it paid. Its line schema is deliberately short: name, quantity, price. It has no unit-of-measure field and no ESF tool. So a draft created by the assistant will often be complete enough to send and still not ready for an ESF: the check will point at the missing unit, the buyer's STIR or the basis document, and a person fills them in.
That boundary is not a missing feature. A legally valid ESF is created and signed at an operator with an electronic signature; the operator contract and API are outside this version. The CRM cannot sign for the firm and should not pretend to. What it can do is make the missing fields visible before someone starts the operator session, keep the register in one place, and show which invoices are still waiting. The printed form and the CSV are working documents, not a substitute for the ESF.
The daily effect is modest and practical. The accountant no longer opens each invoice to see whether the buyer's STIR or the unit is there; the ESF view has already counted it. The issued register shows what is prepared and what is still not at the operator. The received register shows the VAT that lacks a supplier ESF. The operator still issues, the director still signs, and the accountant still decides on deduction. No numbers in this article are client results; they are the rules the code enforces.