ERP–Ecommerce Integration Before the Peak

Uruguay's Cyber Monday event ends today, and Black Friday falls on the 27th. For an operation running physical stores, e-commerce, and an ERP, that calendar does not invent integration problems: it makes them visible, and it makes them visible in front of the customer. What follows is what to review between one date and the next.

Cyber Monday is the rehearsal. Black Friday is the performance

November gives any Uruguayan operation two peaks three weeks apart, and that gap is the opportunity.

The November edition of CIBERLUNES®, Uruguay's Cyber Monday event, ran from 2 to 4 November with more than 115 participating brands. According to the CIBERLUNES Monitor by FACTUM cited by CEDU, 31% of Uruguayans reported buying during the event, with more than 1.1 million transactions and an average of 3.2 items per buyer. Home delivery accounted for 68% of purchases.

That volume does not arrive on an isolated channel. Uruguayan ecommerce billed close to US$ 3 billion over the last rolling year, growing 35% in dollar terms, with roughly 100 million annual transactions and 93% penetration among internet users, according to figures CEDU presented at eCommerce Day Uruguay 2026.

The operational consequence is simple: three days of concentrated traffic against systems that tolerate a fifteen-minute stock lag the rest of the year. During a peak, fifteen minutes means several orders sold against inventory that no longer exists.

The useful part is that Cyber Monday works as a real load test. Whatever broke over those three days is exactly what will break again on the 27th, with more volume behind it. There are three weeks to fix it.

Where it breaks, specifically

ERP–ecommerce integration is not one system: it is six flows that can fail independently. Each breaks in a different way, and the customer sees each one differently.

• Stock: The ERP deducts in an overnight batch; the site sells against yesterday's balance. This generates overselling: an order is confirmed for something that isn't there, and has to be cancelled.
• Prices and promotions: The promotion is loaded manually in each channel. The in-store price doesn't match the site, or the discount doesn't apply.
• Orders: The web order is re-keyed into the ERP, but the dispatch delays, generating data-entry errors and orders that get lost.
• Payments: The gateway confirmation never reaches the ERP, causing paid orders to show as pending or charged twice.
• Invoicing: The e-invoice is issued outside the sales flow, so the invoice never arrives, or arrives with data that doesn't match the order.
• Logistics: Carrier tracking doesn't flow back to the order. The customer writes to ask where their purchase is, and nobody knows.

One detail that matters in Uruguay: 68% of Cyber Monday purchases are delivered to the customer's home, per the FACTUM Monitor. That puts the last two flows in the table (invoicing and logistics) at the centre of the experience, not at its margin.

Payment method matters too. Credit cards account for 53% of buyers, and 81% of those pay in instalments. An instalment plan that doesn't reconcile between the gateway and the ERP is not an accounting problem: it is a stalled order.

What to check now

Seven checks you can run without touching the architecture, in order of impact.

1. Decide which system wins for each data point. If the ERP and the site disagree on stock, price, or order status, there has to be a written answer about which one governs. Without that, every incident is resolved by whoever happens to be on call.
2. Measure actual stock-sync latency. Not the figure in the connector's contract: time how long an in-store sale takes to appear on the site, and the reverse. That number determines how much safety stock you need to hold back per SKU.
3. Test the full path of an order. Purchase, charge, gateway confirmation, ERP record, invoice issuance, dispatch, tracking. End-to-end, with a real order, before the 27th.
4. Check what happens when something fails. If the ERP's API stops responding for ten minutes, does the order get lost, queued, or duplicated? Most integrations are designed for the happy path and discover retries in production.
5. Verify API limits. Rate limits that are ample on a normal day are exhausted within an hour of a peak. Ask your providers for per-minute limits and compare them against the traffic you expect.
6. Check the e-invoicing flow. The invoice should be issued inside the sales flow, not as a manual step afterwards. During a peak, the manual step is the first thing to fall over.
7. Have someone watching the logs during the peak. Not a sales dashboard: integration errors. Orders that never crossed over are invisible in the billing report until the customer complains.

If there's no time left to integrate

Three weeks out from Black Friday, a serious integration project won't land. What will land are three mitigations that reduce the damage without touching anything structural.

Hold safety stock per channel. If syncing takes fifteen minutes, block a buffer on the site proportional to each SKU's sales velocity. You'll sell slightly less and cancel considerably less. During a peak, a cancellation costs more than a lost sale: the customer already formed an impression.

Move the fragile parts to manual, and say so internally. If there's a flow you know is brittle (invoicing, order intake from a specific channel) take it off automatic and assign a person. It's expensive for a few days, and it's predictable, which is what's missing.

Run a daily reconciliation list. At the close of each day, compare web orders against ERP orders. The ones that didn't cross get resolved that night, not the following Monday when the customer writes in.

None of the three is a solution. All three buy time until the 27th, which is when you want to arrive with the problem already solved.

After the peak: from patch to architecture

Most operations get through November on patches and forget about it in December. It resurfaces in March, and the following November the same scramble repeats.

The difference between an integration you have to rebuild every year and one that scales comes down to three design decisions.

Explicit contracts between systems. What data travels in each integration, in what structure, and what happens when it changes. Without a contract, any ERP update breaks the site silently.

Events instead of polling. A system that announces when something changes handles a peak far better than one that asks every five minutes. Under load, polling is the first thing to collapse.

A reusable integration layer. If every new channel (a marketplace, an app, a B2B portal) requires an integration from scratch, cost grows with each channel. An API-first layer is built once and reused.

The moment to make those decisions is not November. It's December, while the peak's incidents are still documented and next year's budget is still open.

At Sagant, we integrate systems across banking, retail, agribusiness, and pharma operations, and we build Komercia, our e-commerce platform for companies with high traffic, large catalogues, and multiple connected systems. If you're weighing what to do after the peak, let's talk.