01 / backbone
Sage 100 is the ledger
Finance, inventory, pricing, order management. The authoritative record the business is run on.
The real problem
Sage 100 runs the business. The store runs the customer. The work is the space between.
Finance, inventory, pricing and order management on one side, B2B buyer self-serve on the other. The gap between the ERP and the storefront is where commerce breaks: duplicate customers, orders written twice, pricing that drifts, silent failures at month-end close.
02 / front door
Shopify is self-serve
Where B2B buyers place repeat orders without a phone call, a rep, or an EDI batch.
03 / the gap
The middle is where it breaks
Duplicate customers. Orders written twice. Pricing that drifts. Silent failures at month-end close.
Our position
We built a product around that exact gap. For Sage 100 the path is fully mapped, and it plugs into the platform as an adapter.
How we connect Sage 100 to Shopify Plus
One direction for master data. Both directions for orders.
Customers, products, inventory and pricing are read out of Sage 100 and pushed to Shopify. The storefront never writes to the ledger. Orders are the only thing that travels both ways, and Sage 100 stays the system of record.
System of record
Sage 100
read · never overwritten
The platform
Makro Middleware.
map · reconcile · audit
The storefront
Shopify Plus B2B
where buyers self-serve
Master data: Sage 100 → Makro Middleware → Shopify, one way
Orders: Shopify → Sage 100, status returns
ProvideX ODBC · readThe SOTAMAS90 driver reads customers, items, warehouse stock and pricing broadly, and writes nothing. Read broadly, write narrowly. We never write the ProvideX or ISAM tables directly, because that bypasses the business logic that keeps the books correct.Sage 100 → MK
Business Object Interface · writeThe COM-based BOI is the only safe write path, reached through
SO_SalesOrder_bus and its peers. Every order writes through Sage's own validation and posting logic, server-resident on the Sage 100 host where ProvideX is installed.MK → Sage 100Poll · stage · queueSage 100 emits no webhooks, so the platform polls, stages, and writes through a durable queue. Inventory and price are prioritized, financial reconciliation is batched, and storefront traffic never lands raw on your ERP.Sage 100 → MK
Named service userA dedicated, least-privileged Sage 100 user authenticates the session. There is no OAuth or token in Sage 100, so permissions are scoped in Role Maintenance and ODBC Security is enabled as a separate gate.handshake
Sales order · UDF external idOrders captured in Shopify are written into Sage 100, status flows back. The webhook is HMAC-verified, deduplicated against a sync ledger, the Shopify id is stamped into a
UDF_ field, and the order is written exactly once.Shopify ↕ Sage 100The console
This is not a connector. It is something you operate.
Every sync, every failure, every reconciliation is visible. This is the same Makro Middleware console your team would watch in production. Move through the views.
console.makro.agency / cascade-industrial-supply / sync
live
Sync Monitor
Sync Monitor
Dead Letter Queue
Observability
Entity Key Map
Schedules
Order Relations
Records / 24h ▲
48,210
across 9 entities
Queue depth
3 pending
2 retrying · 1 review
Avg latency
1.2s
event → Shopify
Last reconcile
04:00
0 drift detected
Activitylive · last 60s
Throughputrecords / hr
In queue
3
of 48,210 processed
Auto-retrying
2
transient · rate-limit
Needs review
1
permanent
Resolved / 24h
41
38 auto · 3 manual
Dead Letter Queuenothing is dropped in silence
| Time | Entity | Error class | Attempts | Next | Action |
|---|---|---|---|---|---|
| 08:13:04 | order · #SO-10288 | PERMANENT · validation | 3 / 3 | held | Inspect |
| 07:55:22 | customer · 01-CASCWEST | USER_LIMIT | 2 / 5 | 09:50 | Retry now |
| 06:40:11 | item · 99320-A | TRANSIENT · timeout | 1 / 5 | paced | Inspect |
Sync volume7-day · records
Circuit breakersper endpoint
Sage 100 · BOIlast trip · never
closedShopify · Admin APIlast trip · 3d ago
closedAvalara · AvaTaxlast trip · never
closedUptime · 90 dayserror rate 0.03%
customer · Cascade Westentity_key_map
sage key01 · CASCWEST
canonical8f2a-c1d9-4e07-44b0
shopify gidgid://shopify/Company/61…
checksuma91f… unchanged
versionv17
→ decision: SKIP · already in sync
Every record carries three identities at once. The Sage 100 key is a composite business key, ARDivisionNo plus CustomerNo, and the middleware reads this row before every write to decide create, update, or skip.
Sage 100 has no native external-ID field and the BOI does not deduplicate, so the platform stamps the Shopify id into a UDF field and keeps a sync ledger keyed by Shopify id. A redelivered webhook writes exactly one Sage document, never two.
Change detection runs on the stored checksum, so a catalog of 50,000 items with 12 real edits syncs 12 records, not 50,000.
Active schedules
7
all workflows enabled
Runs today
96
0 failures
Next run
09:46
inventory levels
Nightly batch
01:00
full read · 48,210 records
Workflowstenant · cascade
Item delta syncODBC · poll + checksumevery 15 min✓ 09:38 · 142 recordsnext 09:53Run now
Inventory levelsper warehouse · bufferedevery 5 min✓ 09:41 · 3 SKUsnext 09:46Run now
Price levels7-level hierarchyhourly✓ 09:00 · 1,204 rowsnext 10:00Run now
Customers & addressesAR_Customer · deltaevery 15 min✓ 09:40 · 6 recordsnext 09:55Run now
Order status returnSage 100 → Shopifyevery 5 min✓ 09:42 · 11 ordersnext 09:47Run now
Full catalog readODBC nightly exportnightly · 01:00✓ 01:00 · 48,210 recordsnext 01:00Run now
Daily reconciliationboth systems vs key mapdaily · 04:00✓ 04:00 · 0 driftnext 04:00Run now
Shopify order#1042
gidgid://shopify/Order/57…
companyCascade West
line 199320-A × 12
line 244120-B × 4
total$8,420.00
#1042↔0100412✓
gid://Customer/88…↔01 · CASCWEST✓
99320-A × 12↔99320-A · qty 12✓
44120-B × 4↔44120-B · qty 4✓
$8,420.00↔8,420.00 USD✓
entity key map · every id matched before write
Sage 100 sales order0100412
SalesOrderNo0100412
customer01 · CASCWEST
line 199320-A · qty 12
line 244120-B · qty 4
statuswritten via BOI
Order journey#1042 → 0100412 · 5s end to end
09:42:04webhook received→
09:42:04HMAC ✓ · dedup ✓→
09:42:05transformed→
09:42:06BOI write queued→
09:42:090100412 written→
09:42:09status → Shopify
drag, scroll, or use the tabs
Inside the platform
Feature by feature.
Ten engineered subsystems sit between Sage 100 and Shopify Plus. None of them is a setting you toggle. Each is something we built, and something your team can watch run.
01 / 10
When a record fails
Integrations are judged by how they fail. Follow one failed record.
Instead of disappearing into a log, every failure is classified before it is retried. Colour carries the verdict: amber is sorted, teal retries, red is held, green replays.
01
It arrives
A record fails to write to Shopify or Sage 100. Instead of disappearing into a log, it enters the pipeline.
captured→ 02
It gets classified
Every failure is sorted before anything is retried. A BOI validation reject is held, a User Limit Exceeded error is paced.
classified→ 03
Concurrency backs off
A User Limit Exceeded error backs off and pools the BOI and ODBC connections until a seat frees, then retries on its own.
retrying→ 04
Permanent is held
A BOI validation reject, like a Shopify customer missing a field Sage requires, routes to the dead-letter queue. Never retried blindly or lost.
held for review→ 05
You replay it
Fix the cause, replay from the queue. A daily reconciliation pass catches anything the live path missed.
replayed · reconciledThe failure modes no vendor page admits
Where off-the-shelf connectors break.
Sage 100 has no native REST API, so a Sage 100 ⇄ Shopify integration is only as good as the middleware engineered behind it. Templated connectors handle the happy path and skip these. A custom layer is built to handle all of them, explicitly.
The table-write bypass
silent corruptionSome connectors write the ProvideX or SQL tables directly to look fast. That silently bypasses the business logic that keeps the books correct. A correct build commits every write through the Business Object Interface and recovers speed with queuing and batching it controls, not by skipping validation.
→ every write through BOI, never raw tablesDuplicate orders
failure mode #1The BOI does not deduplicate, Sage has no native external-ID field, and Shopify delivers webhooks at least once. A retry or redelivered webhook re-creates the Sage order unless the integration owns dedupe. We stamp the Shopify id into a UDF field and keep a sync ledger keyed by Shopify id.
→ idempotency ledger + Shopify-id UDFInventory double-count
days to surfaceSage's raw Available field is configurable and can fold in not-yet-received PO stock, and Shopify owns the committed state itself, which you cannot set through the Admin API. Push Sage Available to Shopify available and you double-count every open order. We sync buffered physical stock, per warehouse.
→ buffered physical stock, per warehouse to locationCustom field mapping (UDFs)
no introspectionUDFs are fully supported but not auto-discoverable. There is no introspection endpoint. Every UDF must be created in Custom Office and mapped by its exact UDF-prefixed name, with a trailing dollar sign for strings. Get it wrong and the field silently fails to map. Budget a field-discovery workstream.
→ explicit UDF discovery + name-exact mappingMulti-currency
single base currencyStandard Sage 100 on ProvideX operates with a single base currency. True multi-currency transacting requires the DSD Multi-Currency enhancement. A Shopify Plus store selling in several presentment currencies cannot assume Sage holds prices per currency, so we handle it with the add-on or in middleware.
→ DSD add-on or middleware FX handlingRefunds and RMA licensing
per-installSage 100 has no standalone fulfillment object, and refunds route through the RMA module to a credit memo. But RMA is a separately licensed module, so not every site has it. A Shopify refund may instead need to land as a posted AR credit memo. We confirm the module exists before assuming the path.
→ RMA credit memo, AR credit memo fallbackThe 64-bit cutover
April 2026The BOI is COM and historically 32-bit, and Sage 100 v2026 is 64-bit-only. 32-bit and 64-bit cannot coexist, so third-party integrations have to be rebuilt in 64-bit. The integration is an owned, versioned, maintained asset, not a set-and-forget license. We scope it 64-bit-ready.
→ 64-bit-ready build, maintained through upgradesClaims you can check
What you will hear, and what the docs actually say.
Every reality below is verified against a primary Sage source, a named vendor doc, or Shopify's own documentation. This is the difference between a team that read the marketing and a team that shipped against the documentation.
01
The claim"Sage 100 has an API you just connect Shopify to."
The realitySage 100 has no native, internet-facing REST API and no outbound webhooks. Its only programmatic surface is Windows COM, the Business Object Interface, for writes and the ProvideX ODBC driver for reads, both behind the firewall. Every "Sage 100 REST API" is somebody's middleware, never a Sage-native endpoint.
02
The claim"There's a native Sage 100 to Shopify connector."
The realityThere is no first-party Sage-built or Shopify-built connector. Sage positions integration as a development-partner exercise through the BOI and Visual Integrator, and Shopify's own community routes merchants to third-party platforms and custom app development. Every option on the market is third-party middleware over BOI and ODBC on a Windows host.
03
The claim"It syncs in real time, just like a cloud API."
The realitySage 100 emits no events. Real-time feel is synthesized by middleware through frequent polling, a fast BOI write, and staging queues. The honest architecture is poll, stage, queued BOI write, with inventory and price prioritized and financials batched. There is no webhook from Sage to lean on.
04
The claim"You can read the live customer-specific price straight from Sage."
The realitySage 100 has no standalone net-price call for a customer, item and quantity. Price is the output of a 7-level hierarchy with up to five quantity breaks. The only authoritative way to get the resolved price is to drive the
SO_SalesOrder_bus object, or to re-implement the whole hierarchy in middleware and validate it against Sage's invoice.05
The claim"Just push Sage's Quantity Available to Shopify."
The realityThe raw Sage Available field is a configurable derivation. Its Include in Quantity Available option can fold in not-yet-received PO stock, so publishing it straight oversells. And Shopify owns the committed state itself, which you cannot set through the Admin API, so writing Sage Available to Shopify available double-counts every open order. Sync buffered physical stock instead.
06
The claim"Sage 100 will handle checkout tax for the storefront."
The realitySage 100's native tax engine has manually maintained rates and is unreachable at checkout, behind the firewall on COM and ODBC. Cart-time tax must run in Shopify, against Avalara's SalesOrder estimate via Shopify's native tax-partner integration. The middleware then posts the permanent SalesInvoice of record into Sage. One Avalara engine, two document types.
07
The claim"The connector won't create duplicate orders."
The realityThe BOI does not deduplicate, Sage has no native external-ID field, and Shopify delivers webhooks at least once, so a retry or redelivered webhook re-creates the Sage order unless the integration owns dedupe. The fix lives in middleware: stamp the Shopify id into a
UDF_ field and keep a sync ledger keyed by Shopify id, so a redelivered webhook is a no-op.08
The claim"Real-time, high-throughput sync, fast."
The realitySage governs by licensed concurrent connections, not request rate, the User Limit Exceeded error, and BOI is local and effectively serialized per session. "High throughput" sometimes means a connector writes the tables directly to go faster, which silently bypasses the business logic. A correct build commits through BOI and recovers speed with queuing it controls.
09
The claim"Custom fields sync automatically, your schema just shows up."
The realityCustom fields, UDFs, are fully supported but not auto-discoverable. There is no introspection endpoint. Every UDF must be created in Custom Office, then mapped by its exact
UDF_-prefixed name, with a trailing dollar sign for strings. Get it wrong and the field silently fails to map. Budget a field-discovery and mapping workstream, not a one-click sync.10
The claim"It's a simple connection, token in, done."
The realityThere is no token, no OAuth, no API key, no scope in Sage 100. The integration authenticates as a named Sage 100 user with a password, or a Windows identity via Unified Logon. Least-privilege lives in Role Maintenance, and ODBC Security is a second, separate gate that is wide-open by default, so a tightly scoped task role can still expose every table over ODBC.
11
The claim"Multi-currency works out of the box for our international store."
The realityStandard Sage 100 on ProvideX operates with a single base currency. True multi-currency transacting requires the DSD Multi-Currency third-party enhancement. A Shopify Plus store selling in multiple presentment currencies cannot assume Sage holds prices per currency, so handle it with the add-on or in middleware.
12
The claim"Refunds just flow back into Sage automatically."
The realitySage 100 has no standalone fulfillment object, and refunds route through the RMA module to a credit memo, but RMA is a separately licensed module, so not every site has it. A Shopify refund may instead need to land as a posted AR credit memo. Confirm the module exists on the target install before assuming the path.
13
The claim"Our connector monitors itself, you'll know if something breaks."
The realityThe operational failure mode is "online orders aren't syncing and nobody knows why," and almost no off-the-shelf connector publishes its retry, replay and reconciliation behavior. Shopify's own docs say webhooks aren't guaranteed and mandate reconciliation jobs. The real answer is per-record observability, a dead-letter queue with replay, daily reconciliation, and on-call paging.
14
The claim"Build it once and you're set, it'll keep working."
The realityBOI is COM and historically 32-bit, and Sage 100 v2026 is 64-bit-only. 32-bit and 64-bit cannot coexist, and third-party integrations have to be rewritten in 64-bit. Crashes from outdated software versions and server issues are a recurring failure mode. The integration is an owned, versioned, maintained asset, not a set-and-forget license.
The decision guide
Three ways to connect Sage 100 and Shopify, and when each is right.
There are three ways to connect Shopify to Sage 100: an off-the-shelf connector app, a middleware or iPaaS platform, and a custom-built integration maintained by a development agency. The right choice depends on order volume, B2B complexity, and how many non-standard rules Sage 100 carries.
Option 01
Off-the-shelf connector
A packaged app over the BOI on a Windows host. Low cost, fixed field mappings, competent on a standard B2C happy path.
- mappingsfixed, limited B2B logic
- recoveryoften undocumented
- surfaceBOI and ODBC, behind the firewall
- fieldsUDFs typically not handled
Right for standard B2C order and inventory sync, with no customer-specific price levels or custom fields.
Option 02
iPaaS platform
Subscription middleware on a shared platform. Strong for standard multi-system sync across templated connectors.
- mappingsconfigurable, template-bound
- tenancyshared platform, row filtering
- pricingannual fee, grows with volume
- B2Bprice levels often an afterthought
Right for standard multi-system sync where Sage's rules fit a fixed-mapping template.
Option 03 our build
Custom middleware
Built around your exact order flow and Sage 100 rules, owned by you, operated with a support agreement. Where Plus and B2B merchants end up.
- mappingsyour fields, UDFs, price levels
- tenancysingle-tenant, isolated per client
- recovery7 failure classes, DLQ, replay
- writesthrough BOI, never raw tables
Right for Sage 100 with non-standard rules: kitting and BOM, multi-warehouse allocation, customer-specific price levels, EDI, or approval workflows a templated field map cannot express.
Timeline and what drives scope
Timeline by scope, not a contact-us wall.
A Sage 100 ⇄ Shopify Plus build lands in one of three bands depending on B2B price-level complexity, the size and shape of the item master, and how many of the break points above are in play.
Band 01 · foundation
single store
standard catalog · core sync
- Customers, items and inventory one way, Sage 100 to Shopify
- Orders both ways, written through the BOI, status returned
- Buffered physical stock per warehouse, overselling prevented
- Dead-letter queue, daily reconciliation, the console
Band 02 · B2B
price levels
Shopify Plus B2B · UDFs
- Everything in foundation, plus the Sage price hierarchy resolved
- Price levels mapped to Shopify Plus B2B catalogs and price lists
- UDF discovery and name-exact custom-field mapping
- Avalara tax handoff at the Shopify edge
Band 03 · complex
multi-rule
RMA · multi-currency · 64-bit
- Everything in B2B, plus kitting, BOM and multi-warehouse allocation
- Refunds via the RMA module, with an AR credit-memo fallback
- Multi-currency through DSD or middleware FX handling
- 64-bit-ready for the Sage 100 v2026 cutover, EDI and approval flows
Cost · scoped per build
We price a Sage 100 integration as an engineering engagement: a build with a support agreement, not a per-record meter or a platform seat that renews forever. For context, off-the-shelf connector apps start from roughly $99 a month and grow with volume, while a custom build is a one-time scoped engagement that removes per-order and volume fees and owns the data-mapping logic. Your exact figure is scoped to the band and the break points in play, and we put it in writing before anything starts.
Security posture
Built to pass your review, and your Sage partner's questions.
Credentials never in plain config
The Sage 100 service-user password and Shopify secrets are held as encrypted fields, isolated per tenant and rotatable without downtime.
vaulted · per-tenantInbound traffic is verified
Every Shopify webhook is HMAC-verified before it is trusted, then deduplicated so a replay cannot create a second order.
HMAC · replay-safeLeast-privilege access to Sage 100
Sage 100 has no OAuth or token, so the integration runs as a named service user scoped in Role Maintenance, with ODBC Security enabled and scoped as a separate gate.
named user · Role Maintenance · ODBC SecurityEverything is on the record
An append-only audit trail logs every operation, source-tagged, so you can prove what happened during close.
append-only · source-taggedFrequently asked questions
Where Sage 100 integrations get hard, and where we land.
The details that separate a team that read the docs from a team that shipped against them. Open any one.
01Does Sage 100 integrate with Shopify out of the box?+
No. Sage 100 has no native, first-party Shopify integration. The two systems are connected either through a third-party connector app or a custom-built integration that uses the Sage 100 Business Object Interface (BOI) to read and write data.
02How does a Sage 100 Shopify integration actually work?+
It uses the Sage 100 Business Object Interface (BOI), a COM-based developer interface, to move data between systems. Shopify orders write into Sage 100, and Sage 100 inventory, pricing, and customer updates write back to Shopify, so the ERP stays the single source of truth. Because Sage 100 emits no webhooks, the integration polls Sage and stages writes through a middleware queue.
03What data syncs between Sage 100 and Shopify?+
Six object types: orders and invoices, inventory levels, customer records and addresses, the product catalog, pricing, and shipping/tracking. Master data flows one way (Sage 100 to Shopify); orders flow both ways.
04Real-time or batch, which sync mode should I use?+
Both are possible. Inventory and orders are usually synced in near-real-time so stock and fulfillment stay accurate, while less time-sensitive data can run on a schedule. The middleware prioritizes inventory and order flow and batches financial reconciliation.
05Can the integration handle B2B and customer-specific pricing?+
Yes. Sage 100 price levels and customer-specific pricing map to Shopify Plus B2B catalogs and price lists, so each wholesale account sees its negotiated pricing. Credit limits, payment terms, order history, quick reorder, and personalized catalogs can also carry through.
06What are the most common Sage 100 Shopify integration problems?+
Duplicate orders written into Sage 100, inventory mismatches, incomplete customer records, failed order or payment status updates, delayed syncs, and middleware errors from Sage 100 version incompatibility. Most are prevented by validating and field-mapping data before it writes into the ERP, and by an idempotency ledger that stops duplicate orders.
07Should I use an off-the-shelf connector or a custom integration?+
Off-the-shelf connectors fit standard B2C order and inventory sync. A custom integration is warranted when Sage 100 carries non-standard rules, kitting/BOM, multi-warehouse allocation, customer-specific price levels, EDI, or approval workflows, that a templated field map cannot express. Makro builds and owns that custom middleware for Shopify Plus merchants.
08How does the integration authenticate to Sage 100?+
Sage 100 has no OAuth or API tokens. The integration authenticates as a dedicated, least-privileged Sage 100 service user (or a Windows identity via Unified Logon), with permissions scoped in Sage's Role Maintenance and ODBC security enabled as a separate gate.
09How do you read a customer's resolved price out of Sage?+
There is no single call that returns the net price for a customer, item and quantity. Sage 100 price is the output of a 7-level hierarchy with up to five quantity breaks. We either drive the
SO_SalesOrder_bus object to read the calculated price, or re-implement the hierarchy in middleware and validate it against Sage's invoice. Then we flatten Sage Price Levels into Shopify Plus B2B catalogs and price lists.10Why not just push Sage's Quantity Available to Shopify?+
Because it double-counts. Sage's raw Available field is configurable and can include not-yet-received PO stock, and Shopify owns the committed state itself, which you cannot set through the Admin API. Write Sage Available to Shopify available and every open order is counted twice. We sync buffered physical stock per warehouse, mapped to a Shopify location, and let Shopify own web commitment.
11What happens at the Sage 100 v2026 64-bit cutover?+
The BOI is COM and historically 32-bit, and Sage 100 v2026 is 64-bit-only. 32-bit and 64-bit cannot coexist, so 32-bit integrations have to be rebuilt. We scope the middleware 64-bit-ready, and because the integration is an owned, versioned, maintained asset rather than a set-and-forget license, the upgrade is a planned task, not a surprise outage.
12Will rollout touch our production data, and are we locked in?+
Master data reads are read-only against Sage 100 over ODBC, and every write goes through the BOI, never raw tables, so Sage's own validation and posting logic always runs. Order writes go to a test company first, then a parallel run with daily reconciliation, and production posting starts when the report says zero drift and you sign off. On the Sage side we use standard surfaces only, and your data, field mappings and full audit trail are yours, documented and exportable.
The framework underneath
A proven platform. Sage 100 is the next adapter.
Every ERP sits behind the same contract: authenticate, fetch master data, push orders, validate, report. The platform runs in production today against NetSuite. Sage 100 is a registered target on that same framework, its path fully mapped to the BOI for writes, ProvideX ODBC for reads, a named service user, and the poll-stage-queue pattern.
We say this plainly: the credibility is a real platform and a precisely understood Sage 100 path, not a decade of Sage 100 traffic. That distinction is exactly what your architect can verify, which is why we lead with it.
adapter contractbase.ts
01authenticate()named user
02fetchMasterData()ProvideX ODBC
03pushOrder()BOI · SO_SalesOrder_bus
04validate()schema check
05report()audit + status
NS
NetSuite
ERP adapter
S1
Sage 100
ERP adapter
Proof and the engineering standard
Claims you can check.
$100K+ / yr
Clarius · enterprise ERP + Shopify PlusWe built a unified account page integrating Clarius' NetSuite ERP, Salesforce CRM and Shopify Plus into a single view of customer information, orders and invoices across three enterprise systems. Combined with Shopify Flow automation feeding order data into NetSuite, it eliminated manual order entry and reduced operational costs by over $100,000 a year. Evidence of our enterprise-ERP and Shopify Plus integration competence, the same standard the Sage 100 path is built to.
1,756
Automated tests across 139 suites, run on every change. No code reaches your production data without passing them.
85%
Coverage gate enforced before any deploy.
39
End-to-end browser tests, across Chromium, Firefox and WebKit.
7
Failure classes, each with its own pre-decided policy.
0
Credentials stored in plaintext, anywhere, ever.
Bring your Sage 100 partner and your connector renewal quote. We will walk the platform, not a deck.
A real conversation about your Sage 100 environment, your data, and the three sharp questions you already have.