Why is my online store selling products that are out of stock?

That is overselling: selling or accepting more units than are actually available. It is almost always an architecture problem, not a lack-of-care problem. A common cause in multichannel operations is stock being stored as a global number that gets overwritten instead of as a history of transactional movements. When several channels (storefront, marketplace, point of sale) access the same inventory at the same time, and synchronization between systems is also delayed or misaligned, two of them can sell the same unit simultaneously without either one knowing.

Does synchronizing systems faster solve overselling?

No. Two real technical constraints make truly instantaneous synchronization impossible: marketplace API rate limits, and the fact that even without those limits there is always a window between a sale and the moment other systems learn about it. The solution is to change how inventory is modeled, not to synchronize more frequently.

What is the difference between modeling stock as a global number and as a movement history?

Stock as a global number means storing a single mutable value ('I have 40 units') that is overwritten with every sale, losing context about what is allocated to pending orders, in transit, or in quarantine. Transactional inventory records every receipt, shipment, and reservation as an event in a history, and calculates availability from that history. That way, even if several channels sell simultaneously, there is a clear record of what happened and the same item cannot be sold twice.

What is the Saga pattern, and how does it help with ecommerce inventory?

When orders, payments, and inventory run in independent services, the Saga pattern coordinates those steps: each one executes and confirms separately, and if one fails (for example, payment), previous steps are reversed through a compensating action rather than relying on a single distributed transaction. Applied to stock, the unit is reserved as part of the order saga and released if payment is not completed — this is explicit compensation within the business flow, not the same as 'eventual consistency' in the strict sense.

Can electronic invoicing block a sale?

Yes, if sales confirmation and issuance of the tax document are coupled within the same transaction: any slowdown or outage in SIFEN blocks the entire sale. The solution is to separate those steps — confirm the sale first and issue the document afterward as a decoupled step — so an isolated SIFEN outage does not prevent the customer from completing the purchase.

How does Pymerce handle stock synchronization between channels?

Pymerce implements two architectural decisions: stock as a transactional movement history by location and product rather than a mutable global number, and separation between sales recording and communication with SIFEN, which occurs afterward as a decoupled step. It uses a transactional database as the source of truth, webhooks as the main trigger, and polling with periodic reconciliation as a fallback. The specific reservation or allocation mechanism used to prevent concurrent sales at the same instant is not publicly documented.

Does SIFEN have to approve a document before an online purchase can be completed?

Not necessarily. The sale and transmission of the document to the DNIT are two distinct moments: the issuer may generate and digitally sign the Electronic Document at the time of sale, then queue transmission to SIFEN for completion within the deadline set by the regulation (up to 72 hours from the electronic signature in the deferred transactional model), without blocking the commercial transaction — provided the regime applicable to the issuer permits it.

If I use webhooks, do I still need polling or reconciliation?

Yes. Webhooks can fail or not arrive for different reasons (timeouts, platforms that do not support them, isolated errors), and integrations between external systems should not assume instantaneous consistency. That is why the recommended pattern combines webhooks as the main trigger with polling and periodic reconciliation as a fallback to detect and correct missed events.

Back to blog

Integrating ecommerce with ERP in Paraguay: how to prevent overselling and automate electronic invoicing

September 25, 2026

ecommerce ERP integration Paraguay
multichannel stock synchronization
preventing overselling Paraguay
ecommerce electronic invoicing Paraguay
transactional inventory architecture
order automation Paraguay
SIFEN and ecommerce

SummaryOverselling is almost never a matter of carelessness; it is an architecture issue: when stock exists as a global number rather than a history of movements by location, two channels can sell the same unit at the same time. Syncing faster does not solve it. A movement history (ledger) provides a source of truth and traceability, but preventing concurrent sales also requires inventory reservations or allocation, plus correct handling of concurrency and idempotency — as well as separating sales confirmation from transmission of the tax document, as Pymerce, Flexora's management platform, does.

Overselling means selling or accepting more units of a product than are actually available. In multichannel operations, delays or mismatches in stock synchronization between systems are a common cause.

The symptom: selling something you no longer have

If your ecommerce operation is already live and you sell through more than one channel (your own store, a marketplace, or a physical point of sale), chances are that at some point a customer has bought a product that was not actually available. That is overselling. In multichannel operations, the risk increases when different systems do not share a sufficiently current and consistent view of inventory.

As Cin7 explains, these synchronization delays or mismatches arise especially when the same operation sells through more than one channel. In integrations that synchronize in batches rather than in real time, that window can be around 15 to 30 minutes, according to Bizowie — this is not a universal duration; it depends on how each integration is configured. A product sells in one channel at 10:05, but if the other system synchronizes every 25 minutes, it will not know until 10:30. During that window, the product appears available everywhere even though it is no longer available.

Synchronizing more often reduces the stale-data window, but it does not solve the concurrency and availability problem on its own.

Why it happens: stock as a global number vs. stock as a transactional record

Most basic systems treat inventory as a global quantity: “I have 40 units of product X.” But in real operations, those 40 units are never one homogeneous number. According to Bizowie’s analysis, inventory exists simultaneously in multiple states — allocated to pending orders, in transit, in quarantine, and actually available — and a system that collapses everything into a single counter loses that distinction.

There is also a structural issue: integrations between external systems should not assume zero latency or instantaneous consistency. API rate limits, asynchronous processing, event delivery, isolated failures, and propagation time all play a role. No matter how optimized the integration is, there is always a window, however small.

The combination of an overly simple availability model and non-instantaneous synchronization increases the risk of overselling in multichannel operations, especially when multiple channels compete for the same inventory.

A more robust pattern: inventory by location and product, with historical movements

Instead of maintaining a mutable global counter, a more robust pattern is to track inventory as a series of transactional movements by location and product: every receipt, shipment, and reservation is recorded as an event, and availability is calculated from that history rather than by overwriting a number.

This is exactly what we implemented in Pymerce, Flexora’s management and sales platform: stock is not a field updated in place; it is a movement history by location and product. This design decision provides complete traceability and a central source for calculating availability consistently: even when multiple sales channels hit the same inventory, every movement is recorded and inconsistencies can be detected and reconciled. A movement ledger solves that — traceability and a source of truth — but preventing races between simultaneous sales (two channels reserving the same unit at the same instant) also requires inventory reservation or allocation mechanisms and concurrency control in the system that processes sales.

This approach aligns with what ECOSIRE documents about real-time synchronization architectures (a secondary source on market architecture, not a regulatory source, but consistent with patterns widely documented in the industry): use a transactional database as the source of truth, webhooks as the primary update trigger, and polling with periodic reconciliation as a fallback when a webhook fails or the platform does not support it.

When order, payment, and inventory run in independent services or systems, a common coordination approach is the Saga pattern: each local step executes and confirms separately, and if one fails (for example, payment), previous steps are reversed through a compensating action instead of relying on a single distributed transaction (as documented by Temporal). Applied to inventory, this means reserving the unit as part of the order saga and releasing it if payment is not completed, rather than leaving it locked indefinitely — a payment-pending reservation is not the same as “eventual consistency” in the strict sense of the term; it is explicit compensation within a business flow.

The role of electronic invoicing in the order flow

A second design consideration is to avoid unnecessarily coupling sales confirmation with tax communication within a single synchronous operation.

Adobe Commerce documentation notes that an order remains editable and cancellable until payment is received and the document is generated — the precise point at which invoicing is triggered depends on how the payment method is configured; it is not a fixed, universal instant.

In Paraguay, electronic invoicing under SIFEN separates three distinct moments, according to Decreto N° 872/2023 and the DNIT e-Kuatia frequently asked questions: first, the issuer generates and digitally signs the Electronic Document (DE) and sends it to the buyer; second, it transmits that signed XML to the DNIT for approval; third, the DNIT validates the document and, if it approves it, turns it into an Electronic Tax Document (DTE) with legal validity, evidentiary force, and tax effect. The transactional e-Kuatia model (intended for medium and large issuers) operates on a deferred basis: as a general rule, regulations establish that transmission must be completed within 72 hours after the date and time of the qualified electronic signature, although the DNIT may set shorter deadlines or require prior approval depending on the issuer’s profile.

Information on SIFEN reviewed as of 25/09/2026.

This means that, when the regime applicable to the issuer allows it, the integration can decouple the SIFEN response from the commercial flow: the sale is confirmed and the DE is generated and signed immediately, while transmission to the DNIT is queued and retried within the applicable deadline if the service is slow or experiences an isolated outage. At Pymerce, we address this by separating sales registration from communication with the tax authority, so as not to confuse issuance of the document (which takes place at the tax-relevant time applicable to the transaction) with its transmission and approval (which follows the schedule established by the regulations for each issuer profile).

This article does not cover the costs or implementation timelines for electronic invoicing in Paraguay — for that, see how much it costs to integrate SIFEN with the DNIT.

There is no single ecommerce technical event — fulfillment, payment capture, or shipment confirmation — that universally determines when document issuance must be triggered: that tax-relevant timing depends on the transaction and the issuer’s profile. What does have explicit rules is transmission of the DE to the DNIT once it has been generated, with the 72-hour deadline serving as the general reference for the transactional model.

Problem	Useful pattern	Limitation
Global stock counter	Movement ledger	Does not solve concurrency on its own
Simultaneous sales	Reservations / allocation	Requires an expiration or compensation policy
Missed synchronization events	Webhooks + polling	Consistency is not instantaneous
SIFEN availability	Decoupled transmission	The issuance timing and DNIT deadlines must be respected

What to review in your operation now

If you are seeing recurring overselling, review these points before thinking about synchronizing faster:

Is your stock modeled as a global number that gets overwritten, or as a movement history by location and product?
Does sales confirmation depend on successful completion of communication with the tax authority, or are they two decoupled steps?

These are two architectural decisions worth reviewing first when overselling or blocked sales appear in ecommerce-ERP integrations.

At Flexora, we work on these integrations through e-commerce services and automation and integration services. Pymerce’s ecommerce module, which applies these same transactional inventory and decoupled invoicing patterns, is currently under development in its final phase.

If you are still planning your ecommerce operation from scratch, the initial checklist is available in what an ecommerce business needs in Paraguay.

Sources cited

Frequently asked questions

Why is my online store selling products that are out of stock?: That is overselling: selling or accepting more units than are actually available. It is almost always an architecture problem, not a lack-of-care problem. A common cause in multichannel operations is stock being stored as a global number that gets overwritten instead of as a history of transactional movements. When several channels (storefront, marketplace, point of sale) access the same inventory at the same time, and synchronization between systems is also delayed or misaligned, two of them can sell the same unit simultaneously without either one knowing.
Does synchronizing systems faster solve overselling?: No. Two real technical constraints make truly instantaneous synchronization impossible: marketplace API rate limits, and the fact that even without those limits there is always a window between a sale and the moment other systems learn about it. The solution is to change how inventory is modeled, not to synchronize more frequently.
What is the difference between modeling stock as a global number and as a movement history?: Stock as a global number means storing a single mutable value ('I have 40 units') that is overwritten with every sale, losing context about what is allocated to pending orders, in transit, or in quarantine. Transactional inventory records every receipt, shipment, and reservation as an event in a history, and calculates availability from that history. That way, even if several channels sell simultaneously, there is a clear record of what happened and the same item cannot be sold twice.
What is the Saga pattern, and how does it help with ecommerce inventory?: When orders, payments, and inventory run in independent services, the Saga pattern coordinates those steps: each one executes and confirms separately, and if one fails (for example, payment), previous steps are reversed through a compensating action rather than relying on a single distributed transaction. Applied to stock, the unit is reserved as part of the order saga and released if payment is not completed — this is explicit compensation within the business flow, not the same as 'eventual consistency' in the strict sense.
Can electronic invoicing block a sale?: Yes, if sales confirmation and issuance of the tax document are coupled within the same transaction: any slowdown or outage in SIFEN blocks the entire sale. The solution is to separate those steps — confirm the sale first and issue the document afterward as a decoupled step — so an isolated SIFEN outage does not prevent the customer from completing the purchase.
How does Pymerce handle stock synchronization between channels?: Pymerce implements two architectural decisions: stock as a transactional movement history by location and product rather than a mutable global number, and separation between sales recording and communication with SIFEN, which occurs afterward as a decoupled step. It uses a transactional database as the source of truth, webhooks as the main trigger, and polling with periodic reconciliation as a fallback. The specific reservation or allocation mechanism used to prevent concurrent sales at the same instant is not publicly documented.
Does a movement history prevent overselling on its own?: Not by itself. A movement ledger provides a source of truth and traceability — you know what happened and when — but preventing two channels from selling the same unit at the same instant also requires inventory reservations or allocation with an expiration or compensation policy, as well as correct handling of concurrency and idempotency in the system that processes sales.
Does SIFEN have to approve a document before an online purchase can be completed?: Not necessarily. The sale and transmission of the document to the DNIT are two distinct moments: the issuer may generate and digitally sign the Electronic Document at the time of sale, then queue transmission to SIFEN for completion within the deadline set by the regulation (up to 72 hours from the electronic signature in the deferred transactional model), without blocking the commercial transaction — provided the regime applicable to the issuer permits it.
If I use webhooks, do I still need polling or reconciliation?: Yes. Webhooks can fail or not arrive for different reasons (timeouts, platforms that do not support them, isolated errors), and integrations between external systems should not assume instantaneous consistency. That is why the recommended pattern combines webhooks as the main trigger with polling and periodic reconciliation as a fallback to detect and correct missed events.