How to integrate industrial scales with SAP (and other ERPs) using IoT

If your plant has an industrial scale and an ERP (SAP, Oracle, Siesa, World Office, SAP B1) but weighings are still captured in Excel or written by hand before reaching the system, you are losing 3 to 8 hours per week per operator on manual capture, and opening the door to weighing errors that affect inventory and invoicing.

The good news: integrating a scale with SAP doesn’t require replacing anything. A scale with a standard serial port (RS-232/485) connects to an IoT gateway that normalizes the data and publishes it to SAP via the API you already have. This guide summarizes how we do it on real Colombian projects.

TL;DR — the architecture in one mental image

[Scale]   →   [IoT Gateway]   →   [Backend/Queue]   →   [SAP / Oracle / ERP]
RS-232        reads & validates    MQTT/REST            OData/RFC/REST
RS-485        normalizes
              publishes

Four components, four decisions. Each covered below.

1. The scale: what it must expose

Most industrial scales (Toledo, Mettler, OHaus, Cardinal, Rinstrum, Chinese brands with a serial indicator) speak one of three protocols:

• Continuous string or command-based RS-232 — the indicator sends weight as text periodically or on command (typical: <STX>P 0023.450 kg<CR><LF>).
• Modbus RTU over RS-485 — the indicator exposes registers with weight, status and units. The most modern.
• Ethernet/IP or Modbus TCP — scales directly on the network. Fewer of these, usually newer or higher-end.

First thing in any project: open the indicator manual and confirm which of the three applies. If the manual is missing, getting the data can take 2–3 days with a serial sniffer. If the scale is very old or the indicator is proprietary without documentation, budget reverse engineering or an indicator swap (~USD 300–600 for a new one with a standard protocol).

2. The IoT gateway: the translator

The gateway is a small industrial computer (industrial Raspberry Pi, Moxa, Advantech, or a custom controller) that:

1. Reads the scale’s serial port.
2. Validates the data (stable weight, in-range, correct unit).
3. Enriches with metadata: operator, batch, product, timestamp.
4. Publishes to the backend.

Why not connect the scale directly to the ERP: SAP doesn’t speak RS-232. And even if it could, a network failure would lose data. The gateway adds three things a direct cable cannot:

• Local buffer on internet loss (critical on the floor).
• Validation before sending garbage to the ERP.
• Operator ID and batch read via keypad or barcode scanner at the same point.

This is exactly the kind of integration covered by the IoT development service at COL0: gateway firmware + capture platform.

3. The backend: intermediate queue, never direct SAP calls

This is where projects fail. Common temptation: the gateway calls SAP directly via OData/RFC on every weighing. Don’t do it that way.

Correct pattern: the gateway publishes the event to an intermediate queue (MQTT, AWS SQS, RabbitMQ). A worker consumes the queue and pushes to the ERP. Reasons:

• SAP goes down or slow at times. The plant cannot pause weighings for that.
• Audit: the queue is raw traceability; the ERP is the final system of record.
• Automatic retries without losing data.
• You can push the same event to SAP and to an operations dashboard in parallel.

We build this pattern as part of the custom software service: backend + queue + connectors.

4. Integration with SAP (or whichever ERP)

The final layer is the politically sensitive one: the SAP owner inside the company is rarely the IoT project owner. Coordinating access is 50% of the work.

Real options on Colombian projects:

ERP	Best integration
SAP S/4HANA	OData REST, BAPI/RFC via SAP Cloud Connector
SAP B1 (Business One)	Service Layer REST or DI API
Oracle JDE / EBS	REST API if exposed; otherwise, view on intermediate DB
Siesa Enterprise	Documented REST API, feasible
World Office, Helisa	Usually requires intermediate DB or exports/imports
Proprietary ERP	Negotiate with vendor; sometimes intermediate table is best

Critical tip: never write directly to SAP tables. Always use the documented API. Writing to tables works in demo and breaks on the first ERP upgrade, plus you lose vendor support.

Real case: plant with 8 scales and SAP B1

Colombian food-sector client. They had:

• 8 Toledo scales with IND-560 indicator (RS-232 continuous string).
• SAP B1 with inventory module.
• Manual weighing, Excel capture, daily flat-file import to SAP.
• 4–7% monthly inventory discrepancy.

What we did:

1. Industrial gateway per scale with operator barcode scanner.
2. Node.js backend with Redis queue for resilience.
3. Worker calling SAP B1 Service Layer on each confirmed weighing.
4. Operations dashboard in Grafana showing per-line weighings in real time.

Outcome:

• Real-time capture, no Excel.
• Inventory discrepancy dropped from 4–7% to <0.5%.
• Auditable batch traceability.
• ROI in 5 months from operator time savings + waste reduction.

This case belongs to the manufacturing sector and combines the electronic scales solution with custom SAP integration.

Typical mistakes we avoid

1. Skipping a pilot with a real scale. Documenting the indicator on paper is not the same as reading it. A week of real-device testing saves months.
2. Asking SAP access on the last day. The SAP technical owner typically needs 2–6 weeks to approve and set up access. Ask on day one.
3. Forgetting the operator ID. A weighing without an operator is useless for audit. Barcode or RFID at the weighing point.
4. No stable-weight validation. Scales oscillate. Capturing the first read pushes garbage data. Wait N seconds of stability before confirming.
5. No retry on SAP outage. If SAP fails and the gateway drops the data, you lost the weighing. Intermediate queue with exponential retry, always.
6. Confusing mirror DB with real integration. Replicating to your own DB is not integrating with SAP — it’s losing the single source of truth.

Feasibility checklist

Before buying a single gateway, validate:

• I have the indicator manual for each scale and know the protocol.
• I confirmed which ERP we have and which API it exposes (Service Layer, OData, REST).
• I identified the ERP’s technical owner and told them about the project.
• I defined how the operator is identified at the weighing point.
• I defined the “stable weight” rule (how many seconds).
• I have budget for a pilot with 1 scale before full rollout.

If you want the extended checklist —applicable to any industrial IoT integration, not just scales— download the free guide in the banner below.

What if it’s not SAP?

The same pattern (gateway → queue → connector) applies to Oracle, Siesa, World Office, Helisa or a proprietary ERP. Only the final connector changes. Architecture investment is the same — connectors are replaceable without touching the rest of the system.

---

Is your plant losing hours capturing weighings by hand? At COL0 we’ve integrated industrial scales with SAP and other ERPs in Colombian plants. Tell us your case or write us on WhatsApp and we’ll tell you in a single call how feasible your integration is and what path to take.