E-Invoicing for Online Stores: How to Stop Doing It by Hand

The scene repeats across thousands of small stores: the order comes in, payment clears through the gateway, and then someone opens the tax authority's system or a separate program and manually retypes the name, the tax ID, the address and the products to issue the invoice. Ten minutes per order, on a good day. At twenty daily orders, that's over three hours of work an integration does in zero.

And it isn't optional: electronic invoicing is already mandatory in most of Latin America, and the European Union is heading the same way. This article explains how the circuit works, what data your checkout has to collect, and how to automate issuance without becoming an accountant in the process.

How the circuit works, in plain language

An electronic invoice isn't a pretty PDF: it's a structured document (XML in almost every country) sent to the tax authority, which validates and authorises it. The PDF your customer receives is only the printable representation of that document. The full circuit:

1. 01The order is confirmed in your store with the customer's tax details.
2. 02The structured document is generated with issuer, recipient, line items, taxes and totals.
3. 03It's signed electronically with your digital signing certificate.
4. 04It's sent to the tax authority (SRI in Ecuador, SAT, DIAN, AFIP… depending on the country), which validates it and returns the authorisation.
5. 05The customer receives the authorised document by email, and you archive the XML — which is the legal document, not the PDF.

The three routes to issuing (and which is yours)

For the great majority of stores, the middle route is the right one: invoicing providers have already solved the signing, the formats and the regulatory changes — which arrive every year. Your job reduces to connecting the store to their API: when the order is paid, the invoice issues itself. How to evaluate and prioritise that connection is in integrations and APIs for your business.

What data to collect at checkout (and what not to)

The invoice gets issued with whatever the checkout captured. Asking for too little means chasing the customer afterwards; asking for too much scares off sales. The balance:

• The tax ID (national ID, RUC, VAT number… by country) with format validation in the field itself: the check digit gets verified on the spot, not afterwards.
• Name or legal name autocompleted from the ID where the authority allows lookups: less typing, fewer errors.
• A "final consumer" option for buyers who don't need a named invoice, where regulation allows it: it cuts friction on small tickets.
• Email address, which you're collecting anyway: it's where the document arrives.
• Nothing else. The fiscal address only if your rules require it on the document; every extra field lowers conversion.

The cases nobody mentions until they hurt

• Credit notes: every refunded return requires its electronic credit note linked to the original invoice. If you automate issuance, automate this too — it's the forgotten half of the circuit.
• The tax authority being down: official systems have maintenance windows and outages. Countries solve this with contingency issuance (issue offline, report later); check that your provider supports it.
• Orders from abroad: exporting goods or services has its own document type and its own tax treatment. Don't improvise: ask your accountant before accepting the first foreign order.
• Withholdings: if you sell to companies, some will withhold taxes and issue you their withholding document. Your system has to record it against the invoice.
• Numbering and sequence: invoices are sequential per issuing point. Two systems issuing on the same sequence (the store and the physical shop, say) is a guaranteed collision — separate the issuing points from day one.

Reconciliation: making invoice, payment and order agree

Issuing is half the job; the other half is the numbers closing at month's end. Three totals must always match: what the store says (orders), what the gateway says (collections net of fees) and what the tax authority says (invoices issued).

• Every paid order has exactly one invoice (or one invoice plus its credit note). Orders without invoices, or invoices without orders, are the two alarm signals.
• The gateway fee doesn't vanish: it gets recorded as an expense with its own document, not "lost" between the gross charge and the net deposit.
• A 30-minute monthly review with the three reports prevents the year-end mismatch that costs days — and fines.
• Export and store the XMLs in your own backup, not only in the provider's portal: the archiving obligation (5-7 years in most countries) is yours, not theirs.

The most expensive mistakes

1. 01Invoicing by hand "for now". "For now" lasts years, and every transcription error is a credit note plus a new invoice.
2. 02Issuing with old dates. Issuance windows are short (same-day or a few days in several countries); saving up the month's orders to invoice on the 30th is an infraction, not a convenience.
3. 03Ignoring rejections. The bounced invoice nobody reviews becomes a sale without a document — among the most expensive infractions there are.
4. 04Switching providers without migrating the archive. Previous years' XMLs must remain accessible; export them before cancelling the contract.
5. 05Not testing credit notes until the first real return, with the customer waiting for their refund.