ERP & Accounting Integration for Maintenance

For a summary of available resources, check out the REST API Overview.

Overview

Fleets that manage maintenance in Samsara still run their financials — general ledger, accounts payable, payroll, procurement — in an ERP or accounting system (NetSuite, SAP, QuickBooks, Sage Intacct, Viewpoint/Vista, Microsoft Dynamics, and others). Integrating Samsara with your financial system connects the shop to finance: maintenance costs flow into accounting automatically, and validated financial data (vendors, cost codes, purchase approvals) flows back into maintenance workflows.

Without an integration, the shop and the back office re-key the same data: a technician closes a work order in Samsara, and someone in accounting types the same parts and labor into the ERP days later. Integration removes the double entry, keeps both systems reconciled, and gives finance real-time visibility into committed and actual maintenance spend.

Integration features

ERP and accounting integrations with Samsara typically cover four areas:

• Work Orders — export completed repair costs (labor, parts, tax, discounts) to your GL and accounts payable.
• Inventory — keep parts catalogs, stock levels, and consumption in sync between the shop and your ERP's inventory or procurement modules.
• Purchases — connect purchase orders raised in Samsara to your procurement and AP workflows.
• Vendors — maintain a single vendor master across Samsara and your financial system.

Integration Points

Integrations range from a one-way export of closed work order costs to full two-way synchronization across vendors, purchase orders, inventory, and labor — the broader the integration, the less re-keying between the shop and the back office.

Syncing Entities

📘

Beta endpoints are live and callable but may still evolve. Preview endpoints (under the /preview/ path) are published API designs for feedback only — they are not yet functional and may change without notice, so do not build production workflows on them. GA of a preview endpoint is announced in the API changelog.

Customer Integration Lifecycle

The high-level steps an end customer of both Samsara and the ERP/accounting system takes during implementation:

1. Customer setup and installation
2. Initial data synchronization and mapping
3. Day-to-day operations

Customer setup

Customers install your integration either from the Samsara App Marketplace, or when redirected to Samsara via your OAuth authorize link. After the OAuth flow is complete, your integration stores the OAuth credentials and uses the access token to authenticate API calls for the customer's Samsara account.

⚠️ Ensure your OAuth 2.0 application requests the correct scopes: Read/Write Work Orders, Read/Write Parts (under the Work Orders category — covers the parts catalog, inventory locations, and stock movements), Read Assets, and any additional scopes for the entities you sync.

Review the OAuth 2.0 guide for implementation details.

Initial data synchronization and mapping

When a customer connects your integration for the first time, map the existing entities in the ERP to entities in Samsara.

Recommendation: Store the Samsara ID of objects in your ERP-side database, and update the Samsara object's external IDs with the ERP-specific ID (e.g., the NetSuite internal ID or QuickBooks vendor ID). This gives you a durable two-way key and makes every subsequent sync idempotent.

Map the chart of accounts. The single most important setup step. Decide how Samsara maintenance data maps to the customer's GL:

• Labor → e.g., "Fleet Maintenance — Internal Labor" expense account
• Parts → e.g., "Fleet Maintenance — Parts" expense account or inventory asset account
• Outside repair (vendor work orders) → e.g., "Outside Services" AP expense
• Tax and discounts → per the customer's tax treatment

Samsara service tasks carry a category and subcategory (GET /maintenance/service-tasks), which most customers use as the mapping key to GL accounts or cost codes. Store this mapping in your integration's configuration — one mapping table per customer.

Sync Vendors. Pull the vendor list from both systems and reconcile. Vendor records in Samsara carry externalIds and a legacy vendorId from the source system, which you should populate with the ERP vendor ID. See the Vendors section below.

Sync Assets. Work orders reference a Samsara assetId. If the ERP tracks assets (fixed-asset ledger, equipment costing), map ERP asset records to Samsara assets by VIN or serial number using the Assets API.

Backfill history (optional). Use GET /maintenance/work-orders/stream with a historical startTime to import past work order costs, so finance reporting starts with a complete picture.

Day-to-day operations

1. A work order is completed in Samsara — parts consumed and labor logged against service tasks; your integration picks it up from the work order stream.
2. The integration posts it to the ERP — labor, parts, tax, and discount coded to the mapped GL accounts as an AP bill / journal entry. The Samsara work order ID is stored on the ERP record; the ERP transaction ID is written back to Samsara as the invoiceNumber or an external ID.
3. Purchases stay linked — a purchase order raised in Samsara or the ERP is mirrored to the other system, referencing the shared vendor record; the work order's poNumber field ties the repair to the purchase.
4. Invoices close the loop — AP scans vendor invoices into Samsara with POST /maintenance/invoice-scans, and finance reports maintenance spend by asset, cost center, and GL account — fully reconciled, with no re-keying.

Work Orders

Customer problem: "My technicians close work orders in Samsara, but accounting re-enters every repair into our ERP to get costs on the books."

The Work Orders API is the core of a finance integration. A completed Samsara work order carries everything an AP bill or journal entry needs:

Recommended pattern: poll GET /maintenance/work-orders/stream with an updatedAtTime cursor, filter for Completed/Closed statuses, transform each into an AP bill (internal labor can post as a journal entry instead), and PATCH the ERP transaction reference back onto the work order. The stream endpoint returns changed work orders, so re-running the sync never misses or duplicates records if you key on the work order ID.

Use GET /maintenance/service-tasks to resolve service task categories/subcategories for GL coding.

Inventory

Customer problem: "Parts inventory is a financial asset. My ERP has to know what's on the shelf and what got consumed — today those are two different worlds."

The Parts APIs (beta) expose the parts catalog and per-location stock for real-time two-way sync:

• Catalog: /maintenance/parts (full CRUD) — part definitions with part number, barcode, unit cost, unit of measure, and VMRS code. Match parts to your ERP item master on partNumber (or barcode).
• Stock by location: /maintenance/parts/inventory-location — per-part, per-location stock levels and reorder settings. Quantities are read-only here — they change only via stock movements, which keeps the audit trail intact.
• Stock movements: POST /maintenance/parts/stock-movements — post receipts, adjustments, and transfers from your ERP or procurement system so shelf quantities stay reconciled.
• Consumption: every part used on a work order appears in serviceTaskInstances[].parts[] with quantity and unit cost — sufficient to post inventory consumption per repair.
• Transaction history: GET /preview/maintenance/parts/transactions (preview — design only; see the note under Syncing Entities) — an append-only audit log of receives, consumption, scraps, adjustments, and transfers, designed for inventory-valuation reconciliation.

Recommended pattern: sync the catalog two-way keyed on part number, with your ERP as the source of truth for valuation. Post consumption from closed work orders to the GL, mirror ERP receipts into Samsara as stock movements, and reconcile balances against GET /maintenance/parts/inventory-location on a schedule.

Purchases

Customer problem: "We can't adopt a maintenance system whose purchases don't hit our procurement and AP flows — POs are how our finance team controls spend."

Purchase orders created in Samsara are natively linked to parts inventory and work orders, giving fleets a real-time view of committed maintenance spend. The Purchase Order API is in preview (/preview/maintenance/purchase-orders, full CRUD — design only; see the note under Syncing Entities): the published design covers PO headers (vendor, status, GL code), part lines with ordered and received quantities, lifecycle timestamps from sent-to-vendor through fully-received, and the vendor invoice number for three-way match against the AP bill. Once live, POs raised in Samsara can flow into ERP procurement for approval and payment, and ERP-raised POs can appear in Samsara for receiving.

Until then, integrate purchases at the work-order level: the poNumber and invoiceNumber fields plus the invoice-scan endpoint cover the reconciliation loop for most customers.

Vendors

Customer problem: "Every system has its own vendor list. When they drift, invoices get coded to the wrong supplier and 1099s are wrong."

The Vendors API (beta) exposes the maintenance vendor master:

• GET /fleet/maintenance/vendors — vendors with externalIds (write your ERP vendor ID here), vendorId (legacy source-system ID), addressId (join to the Addresses API for full address), and categoryIds.
• GET /fleet/maintenance/vendor-categories — resolve category names.

Recommended pattern: make the ERP the system of record for vendor creation (that's where W-9s and payment terms live), and sync vendors into Samsara so that work orders and POs always reference a vendor that exists in AP. Match on external IDs; fall back to normalized name + address matching only during initial reconciliation.

Related financial data

• Technician labor → payroll and job costing: work orders return per-task technician timeEntries (clock-in/out per service task) for organizations using Technician Management. GET /maintenance/time-entries/stream (beta) provides a cursor-based feed of time entries for payroll-grade export without re-reading work orders.
• Asset depreciation: GET /assets/depreciation (beta) returns depreciation and adjustment transactions per asset with cost center attribution — for fixed-asset subledger reconciliation and TCO reporting.
• Invoice ingestion: POST /maintenance/invoice-scans pushes AP-received vendor invoices into the maintenance record automatically, attaching to an existing work order or creating one for the asset.

Choosing the Right Integration Approach: Polling vs. Webhooks

1. Polling (Batch) — Poll the work order stream endpoint on a schedule (e.g., every 5–15 minutes) with a persisted cursor. This is the recommended approach for financial data: it is simple, replayable, and naturally idempotent. Most accounting close processes are batch-oriented anyway.
2. Webhooks (Event-Driven) — Samsara webhooks push events as they happen. Use webhooks to reduce latency for operational triggers (e.g., notify procurement when a PO is created); pair them with periodic polling for reconciliation.

For financial records, always design for idempotency: key every ERP transaction on the Samsara work order ID (or PO ID), and store the ERP transaction ID back on the Samsara object. Re-running a sync must never double-post to the GL.