# How to add a mobile app to Sage 100

> Source: https://netray.co/integrations/sage-100-mobile-app
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Integrations

## Short answer

Sage 100 is a Windows desktop ERP with no general mobile client for the warehouse or shop floor, so you pair it with a barcode or mobile add-on, or build a thin app and API layer that reads over ODBC or SQL and writes through the Business Object Interface. Plan for server-side validation and offline queues.

## System

Sage 100

## Capability

mobile-app

## Intro

Warehouse staff, drivers and supervisors do not sit at a Sage 100 workstation. They need to receive a PO, move stock, pick an order or report labor from a handheld or phone, and right now many of them write it on paper for someone to key later.

That delay is where inventory accuracy dies. Receipts are posted a day late, counts are off, and the question 'do we have it' gets answered from memory.

There is a mature third-party market for Sage 100 barcode and warehouse mobile products, and a custom path for the odd workflows they do not cover. The right choice depends on how standard your processes are.

## Use Cases

### PO receiving by scan

**Description:** Scan the PO and item barcodes, enter quantities and post a receipt, with over-receipt rules enforced.

### Pick, pack and ship confirmation

**Description:** Show open pick lists, confirm quantities by scan and trigger shipment entry with weights and tracking.

### Inventory transfers and counts

**Description:** Move stock between warehouses and bins and do cycle counts from a phone, with variance review before adjustment.

### Shop-floor labor and work order status

**Description:** Report time and quantity completed against work orders where the Work Order or Bill of Materials modules are in use.

### Manager approvals on the move

**Description:** Approve POs, credit holds or timesheets from a phone, with an audit trail.

## System Surface

Business Object Interface (COM): create receipts, transfers, adjustments and sales order updates with Sage validation. A server-side API layer wraps it so the phone never touches COM.

ODBC or SQL reads: items (CI_Item), item warehouse quantities (IM_ItemWarehouse), open sales orders and POs for lookups. Premium on SQL Server scales better for many handheld users.

Third-party Sage 100 mobile and warehouse products: commonly use BOI or a service on the Sage server; vendor and feature set vary by release, so verify compatibility with your version.

Visual Integrator and scheduled jobs: a batch option for lower-frequency data such as nightly counts or price updates.

Sage 100 licensing: BOI sessions and added users consume licenses, which matters when many devices post at once. Confirm how your license model treats service accounts.

## How It Works

### Decide buy versus build

**Detail:** If receiving, picking and counts are standard, evaluate an existing Sage 100 warehouse mobile product first. Build only for workflows it cannot do.

### Create an API layer

**Detail:** A service on the Sage network exposes narrow endpoints such as lookup item, get PO, post receipt. It uses ODBC or SQL for reads and BOI for writes.

### Authenticate users and devices

**Detail:** Use SSO or PINs mapped to Sage users, and register devices. Attribute every transaction to a person.

### Build the app for scanning

**Detail:** A PWA or native app with camera or hardware scanner support, big touch targets and fast item lookup by barcode or UPC field.

### Handle offline and retries

**Detail:** Queue transactions with unique IDs, replay them in order, and make endpoints idempotent so a retry never doubles a receipt.

### Reconcile and monitor

**Detail:** Show queue status to supervisors, alert on failed postings, and run a daily reconciliation of device transactions to Sage.

## Example Flows

### Receiving a purchase order

**Trigger:** A truck arrives with a PO shipment.

**Steps:**

- The receiver scans the PO barcode and the app loads open lines.
- They scan each item and enter counts; over-receipt triggers a prompt.
- The API posts a receipt through BOI.
- The app shows the on-hand change and prints putaway labels.

**Result:** Stock is available to sell the same hour, not the next day.

### Cycle count with review

**Trigger:** A supervisor assigns a bin count.

**Steps:**

- The counter scans bin and item, entering a quantity.
- The app compares to system on-hand and flags big variances.
- A supervisor reviews and approves.
- An adjustment is posted with the reason code.

**Result:** Counts are controlled and adjustments carry an approver.

## On Prem

A mobile app for an on-prem Sage 100 does not need Sage on the internet. Keep the API layer on the LAN, reachable from handhelds over Wi-Fi, and use a VPN or a reverse proxy with strong authentication for off-site users such as drivers. The app itself can be an internal PWA served from your network. If you add a voice or natural-language assistant for the floor, run the model on a local GPU server so item and order data stay on your premises.

## Security

- Never put ODBC or BOI credentials on a device; they live only on the API server.
- Use per-user authentication and revoke lost devices promptly.
- Enforce permissions server-side, for example who may adjust inventory.
- Encrypt traffic and offline queues on the device, and clear them after sync.

## Options

### Off-the-shelf Sage 100 warehouse or barcode add-on

**Fit:** Standard receiving, picking and counts with supported handhelds.

**Effort:** Weeks, including hardware and label setup, plus licensing cost.

### Custom API and PWA built in-house

**Fit:** Unusual workflows and a team that can run a service next to Sage.

**Effort:** Two to four months for a solid first version.

### Partner-built app with Netray assistance

**Fit:** You want custom flows plus an optional private AI assistant for the floor.

**Effort:** Typically a couple of months, scoped by workflow.

## Pitfalls

- Letting the app write directly to tables rather than through BOI, bypassing Sage logic.
- No idempotency, so a retry on poor Wi-Fi double-posts a receipt.
- Licensing surprises when many concurrent BOI sessions each use a seat.
- Barcodes that do not match item codes; plan UPC or cross-reference data before go-live.
- Underestimating dead zones in the warehouse and skipping an offline mode.

## Faq

### Does Sage 100 have its own mobile app for the warehouse?

**Answer:** Not a general one in the standard product. There are third-party Sage 100 mobile and barcode solutions, and some Sage offerings for specific roles, but availability changes by release. Verify compatibility with your exact version before choosing.

### Can a phone post transactions to Sage 100 directly?

**Answer:** Not directly. The phone talks to an API on your server, and that service posts through the Business Object Interface. This keeps credentials off devices and enforces Sage validation.

### How do I handle poor Wi-Fi?

**Answer:** Queue transactions on the device with unique IDs, replay them when connected, and make the server ignore duplicates. Also show the user clearly which scans have synced.

### Is Sage 100 Standard fast enough for many handhelds?

**Answer:** It can be strained with many concurrent users on file-based data. Premium on SQL Server handles concurrency better. Test with realistic device counts and consider caching lookups.

### Can the app use AI?

**Answer:** Yes, for things like voice lookups or reading labels, but keep it advisory. Run models locally if item and order data should not leave your network, and keep posting actions behind explicit confirmation.

## Search terms

sage 100 mobile app, sage 100 barcode scanning, sage 100 warehouse management mobile, mas 90 mobile, sage 100 inventory app, sage 100 receiving app, sage 100 shop floor mobile, sage 100 handheld scanner, sage 100 api mobile, sage 100 offline mobile app

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json
