How to Connect Multiple Sites to the Same ERP: Secure Networking and Document AI

In a distribution company with several sites, the problem rarely shows up in just one place. An order lands in the sales mailbox; someone has to work out which customer and which branch it belongs to; the team at that site needs to work against the same ERP as everyone else; and then management needs to compare sales, purchasing and stock on a common basis. If each site is connected differently, the firewall has been set up without a shared approach, or ERP extraction competes with day-to-day operations, technology ends up setting the pace of the business. At Congelados Herbania, the architecture can be told as a journey: protect access with Fortinet and VLAN segmentation; join the sites with permanent IPsec tunnels; read Oracle/SIGES read-only with hourly incremental loads; and place an AI application on Amazon Bedrock to read invoices, delivery notes and orders. The aim is not to add up three projects, but to make sure the document that arrives by email ends up as useful work within the same operation.

The problem is not having several sites, but operating as one company

Having several sites is not a technical problem in itself. It becomes one when each site solves the same thing differently and the company no longer has a single version of its operations.

One operation, many ways in

One customer emails an order to a branch, another phones head office and a third confirms with the sales rep who visits them. The order is the same business object, but it comes in through different doors. The same goes for supplier invoices: they arrive as PDFs in the accounts mailbox, on paper at the warehouse receiving the goods, or stapled to the delivery note the haulier signs. If every door has its own process, the company ends up living with as many versions of the same order as it has sites, and the subsequent reconciliation becomes a permanent manual chore.

What should be joined up and what should be kept apart

The answer is not to unify everything. What should be joined up is the business logic: a single ERP, a single customer and product master, a single approach to pricing and costing. What should be kept apart is the risk: warehouse traffic has no reason to see the accounts network, and a laptop connecting from outside should not reach the same systems as an office workstation. Joining up operations and separating the network are complementary decisions, not contradictory ones.

Perimeter firewall and segmentation: the foundation of the network

Before talking about the ERP we have to talk about the network, because everything else rests on it. The perimeter is built on a multi-model Fortinet estate spread across sites on different islands and on the Spanish mainland, configured to the same standard everywhere: this is the work we describe in perimeter firewalls and multi-site networks.

Multi-model Fortinet, VLANs and function-based policies

Multi-model means that not every site has the same appliance — and there would be no point in them having one: a small branch does not need the same firewall as head office. What is common is the approach. Each site is segmented into VLANs by traffic function — office workstations, warehouse, network devices, guest access — and policies are written between functions, not between individual machines. That way, a rule can be understood just by reading its name: which function talks to which, and why.

That discipline pays off very practically on the day something has to change. When a site adds a new system, there is no need to rebuild the firewall: you decide which function it belongs to and it inherits that function's policies. And when something goes wrong, segmentation limits the blast radius: a compromised device in the warehouse cannot reach the accounts workstations or the management network by default.

Hub-and-spoke: connecting sites to work against the same ERP

With the perimeter sorted, what remains is the thing that turns several sites into one company: all of them working against the same ERP without exposing it to the internet.

Permanent IPsec tunnels between sites

The topology is hub-and-spoke: each branch maintains a permanent IPsec tunnel to the central node where the ERP lives. Permanent means it does not depend on anyone bringing it up; it is established and renegotiates itself. For a user at any site, the ERP behaves as if it were in the next room: there is no different procedure for being on another island.

This way of connecting has a consequence that is often overlooked: the ERP does not need to be published on the internet. There is no port open to the outside world and no extra gateway to keep patched. Access comes through the tunnel or not at all, and control sits once again with the same firewall that already governs each site's network.

Remote access for people working away from the office

Site-to-site tunnels take care of the offices, but not of someone working from a hotel, from a customer's premises or between visits. For them there is remote VPN access with a locked-down cryptographic proposal and perfect forward secrecy, so that compromising one session key does not allow earlier sessions to be decrypted. It is a different connection from the one linking the sites, with its own policies, which is why it is also treated as a separate network within the firewall.

Oracle/SIGES as the common ERP, without turning the network into a bottleneck

Oracle/SIGES is where purchasing, sales, invoicing and stock live. Having every site work against it is the goal; the risk is that the same system also has to serve whoever wants to analyse it. That division of labour is what we explain in detail in integrating Oracle SIGES with Power BI (in Spanish).

Read-only access, hourly incremental loads and WAC

Extraction is read-only. The analytics process does not write to the ERP, does not lock tables and cannot alter any operational data: its permissions simply do not allow it. Nor is everything read every time. Airflow orchestrates incremental loads that pick up new movements every hour, keeping the volume per run to a fraction of what a full copy would involve and preventing extraction from competing with day-to-day operations. It is worth being precise: the information is refreshed every hour, not in real time, and for the decisions it supports, that is enough.

The calculation that needs the most care is weighted average cost. SIGES updates it automatically by item and by batch with every goods receipt, and as long as purchases are just purchases, the result is reliable. It gets distorted in three well-known situations: customer returns that go back into stock valued at selling price, stock adjustments, and retrospective discounts that change the cost of a purchase already recorded. Knowing those three things exist is what allows them to be handled in the analytics layer, rather than discovered on the day the margin does not add up.

From email to ERP: the order as a new operational entry point

So far, the architecture lets someone at any site work against the ERP. The next limitation is of a different kind: that person still has to type in by hand whatever arrives written in a document.

Invoices, delivery notes and documents with no per-supplier templates

The AI application reads invoices, delivery notes, quotations, orders and credit notes without a template for each supplier. That is the difference from traditional capture systems: you do not have to teach it where each field sits in every issuer's layout, because it does not work by position but by understanding the document. A new supplier requires no configuration at all.

From each document it extracts who issued it and who it is addressed to, with their tax ID (CIF); what type of document it is; its number and date; and then, line by line, the reference, description, quantity, unit, price, taxable amount, VAT and total. The result is the document turned into comparable data — exactly what someone used to copy out by hand.

The emailed order: customer, branch, catalogue and reply

Orders follow their own path, and they are the only flow written automatically into the ERP. The application reads the sales mailbox via Microsoft Graph, identifies which customer the order comes from and which branch it belongs to, matches the requested products against the catalogue — even when the customer calls them by their own names rather than the ERP's — enters the structured order into Oracle/SIGES and replies from the same sales mailbox. Email stops being an inbox and becomes an operational entry point.

Document AI runs on top of the existing process

One design decision shapes everything above: the AI does not replace the process, it runs on top of it. The ERP is still the ERP and the approval workflow is still the one it always was; what changes is who does the reading. That is how we approach document AI applications.

Amazon Bedrock in the client's own cloud account

The model that reads the documents is Claude Sonnet 4.5, called through Amazon Bedrock, and the important detail is where: in the client's own cloud account. Documents are not sent to a third-party platform; the application calls the model from the company's own infrastructure, with its permissions and its activity log.

Technically, the document is read directly. There is no preliminary OCR stage converting the image into text on which every later error depends: the model interprets the document as it is, and that includes correcting the orientation when someone has scanned an invoice sideways or upside down. It is a small difference on paper and a big one in practice: a large share of the failures in traditional capture systems originate in that step between image and text.

On outputs, it is worth repeating the limit: automatic entry into the ERP is confirmed for orders. All other documents are delivered in structured form for use by the process that already existed.

From ERP movements to Power BI

With operations sorted, one question remains — management's: comparing sales, purchasing and stock across sites on a common basis. That is the layer we cover in data warehousing and Power BI.

A data warehouse kept separate from operations

The movements Airflow extracts from the ERP land in a data warehouse built on managed PostgreSQL in AWS Aurora or on Snowflake, depending on the case, and the Power BI dashboards sit on top of it. The reason for keeping that warehouse separate from the ERP is not aesthetic: a heavy analytical query run against the operational database slows it down for everyone, and the one who pays is the site that happens to be invoicing at that moment. With the two kept apart, analysis can be as demanding as it needs to be without anyone in a warehouse noticing that someone is looking at a report.

The bad day is part of the architecture too

An architecture is judged by how it behaves when something fails. Firewall configurations are version-controlled, so any change can be compared with the previous one and rolled back without rebuilding anything from memory. Endpoints run EDR/XDR with Wazuh, which watches behaviour rather than just known files, and centralises events from every site in one place.

Identity and collaboration rely on Microsoft 365 with Teams and Entra ID, and on Google Workspace where appropriate, with the same access policy in both. And email — the way in for orders, and also for fraud — has SPF, DKIM and DMARC configured on the domain, which is what stops a third party from writing on the company's behalf. These are unglamorous controls. They are the ones that make the difference on a bad day.