Fiscal receipts for an online store in Kyrgyzstan: what it means for development

A caveat first: we're developers, not tax advisers. What your particular activity requires is a question for your accountant, and nothing below replaces them. This article is about something else: what fiscalisation means for the estimate and the timeline, and why it belongs in the first call rather than the week before launch.

Where the problem comes from

The scenario repeats from project to project. The store is ready, the catalogue is filled, payments work — and then the accountant asks where the receipt goes. It turns out the receipt goes nowhere, because nobody planned for it. Launch slips, the budget grows, everyone is unhappy.

Usually nobody is at fault. A client isn't obliged to know that taking an online payment and issuing a fiscal receipt are two different tasks. And a contractor who has only built brochure sites sincerely believes “connecting payments” is one button.

Why it's separate work

A payment gateway and fiscalisation solve different problems. The gateway takes money from a card. The fiscal receipt confirms the sale to the tax authority. Different systems, different contracts, different points of failure.

From a development standpoint this adds:

• Another integration with its own data format and its own errors.
• Failure paths. The money went through but the receipt didn't — what the customer sees, what the manager sees, what the system does. That isn't a rare case, it's an ordinary Tuesday.
• Refunds. A refund is a fiscal event too and has to be recorded correctly.
• A test environment. You can't test on live receipts, so you need a sandbox and time for it.

In practice this adds a noticeable chunk of work, which is why we quote it as its own line: you can see what you're paying for and decide whether you need it at launch.

When you can do without it

Not every store needs online payments from day one. If you take cash on delivery or bank transfers, the situation is different and the receipt question is settled outside the website. For many, it's smarter to launch without online payments, watch real orders, and add them in a second phase — together with fiscalisation, now knowing the volumes.

We say this openly even though it shrinks the first estimate. A store that launched a month earlier and started selling beats a store that is still “almost ready”.

What to settle with your accountant before the estimate

For us to price it correctly we need four answers, and they come from your accountant, not from us:

• Whether a fiscal receipt is required for your activity and payment method.
• Which solution you use or plan to use.
• Who signs the contract with the operator, and in whose name.
• How refunds work in your case.

With those answers the estimate becomes precise. Without them any number is guesswork, and we don't like guessing in an estimate.

In short

Fiscalisation isn't a checkbox in an admin panel but a separate integration with its own timeline, failure modes and testing. Ask about it before signing: if the contractor asks what it is, you've learned the main thing about them.

How we price stores and what the lower bound includes is in the pricing article. What a store project covers end to end is on the web development page.