Your operations run in your own system. Your books live in QuickBooks. We build the two-way sync between them, with rules for who owns each record, so finance and operations see the same numbers without typing anything twice.
The two products look alike to an accountant. To an integration they are different systems, with different APIs, hosting and ways to detect change.
Each item is from a production ERP we built or support. The QuickBooks Online API also covers bills, payments and other entities, which we add when your ownership table calls for them.
Purchase orders are created where the buying happens and reach QuickBooks with their vendor attached. Each purchase order links directly to its vendor in the ERP.
Invoices sync two ways, with tax and tariff logic applied and invoice date mismatches handled by agreed rules instead of by hand.
Each customer profile in the ERP stores its QuickBooks ID next to accounting, order and shipping tabs, so records are matched by ID, never by name.
When an item ID changes on the QuickBooks side, new invoice lines use the new ID automatically. Vendor fields are mapped the same way.
Most broken syncs fail on an unwritten rule, not on an API call. Before we write code, we agree with your finance team which system creates each record type and which one only reads it.
The split on the right is a typical starting point for a manufacturing or distribution ERP, not a fixed template. If a record owned by the ERP is edited in QuickBooks, the sync flags it for review instead of copying the change back or overwriting it.
ERP reads and caches them. Accountants manage them.
Pushed to QuickBooks. The QuickBooks ID is stored on the ERP customer.
If purchasing lives in the ERP, the ERP owns vendors.
Each ERP item maps to a QuickBooks Item ID.
QuickBooks is the ledger. Edits after posting go through the ERP.
Payment status flows back for order and credit views.
A QuickBooks sync is small in lines of code and large in edge cases. These are the pieces we build in, with the project or the guide section where each one is described. Our two-way sync guide has the full detail and Intuit sources.
Every synced record keeps both IDs: a QuickBooks ID column on the ERP entity, or a mapping table when there are many entity types or companies. Merges repoint the mapping. Deletes are marked, not erased.
Intuit’s API accepts a requestid on each write and returns the original response if the same ID arrives again. We generate it once per outbound job and reuse it on every retry, so a network error never creates a second invoice.
Each QuickBooks entity carries a SyncToken. If it changed since we read it, the update fails with error 5010. ERP-owned fields are re-read and reapplied. Anything else goes to a review queue with both values and the rule that failed.
The user saves to the ERP and moves on. Background jobs talk to QuickBooks, one queue per company, with a shared rate limiter and backoff on HTTP 429. Validation errors are not retried; they go to the error queue.
Webhooks report changes quickly but can be missed or arrive out of order. Intuit recommends a Change Data Capture call back to the last processed event and a daily CDC sweep. CDC covers the last 30 days.
A report compares counts and totals per day in both systems, lists records with no QuickBooks ID and shows open errors by age. Rounding happens once, at a defined step, and is tested to the cent.
The business buys raw materials, runs production orders and ships goods. Before One Motion ERP, inventory, purchasing, shipping, accounting and reporting lived in separate tools. OSKI develops the platform and supports it in production, including the QuickBooks link.
Inventory, orders and accounting each lived in a different place, and every retyped record was a chance for an error. Managers could not see order status or stock without checking several systems.
OSKI built one platform on .NET 8, React and MySQL. Through the QuickBooks API, purchase orders and vendor data sync automatically. Each purchase order links to its vendor, and customer profiles keep their QuickBooks ID.
Intuit throttles the REST API per company and app and returns HTTP 429 when you exceed it, with advice to wait 60 seconds before retrying.
Cost is part of the design too. Under the Intuit App Partner Program, Core calls, mostly data-in such as creating invoices or vendors, are unmetered. CorePlus calls, mostly data-out such as reads, queries and reports, are metered. So we read only what changed and cache reference data.
Sources: Intuit Developer, API call limits and throttles, OAuth 2.0 and App Partner Program FAQ, as summarized in our October 2026 guide.
days of history covered by Change Data Capture. That is why a daily sweep runs next to the webhooks: a missed event is caught the same day, not at month end.
Accounting sync bugs are expensive because they surface late, often at month end. We settle ownership, mapping and rounding with your finance team first, then build.
Related: ERP development when the operations system itself needs building, integrations and automation for other tools, e-commerce development for order-driven businesses, and Amazon SP-API integration when sales start on Amazon.
Online or Desktop, which edition, how many companies, and whether a move is planned. This decides the API, the hosting and the change detection.
Record by record, which system creates it and which one only reads it. Finance signs it off, and the code enforces it.
Vendor fields, tax codes, item IDs, units and rounding. We test real invoice samples from your business in a sandbox company.
Background sync, retries, conflict routing and a screen where finance can fix a missing tax code and press retry.
The daily comparison report runs from day one. We support the sync in production and extend it as rules change.
Two ERPs synced with QuickBooks, and a fulfillment platform that bills clients at the right stage of each order.
A custom ERP that brings inventory, order processing, purchasing and reporting together and keeps vendor data in sync with QuickBooks.
An internal ERP that replaced separate tools for inventory, purchasing, shipping and reporting, with a two-way QuickBooks sync the finance team can rely on.
A sourcing step that buys from 1688 suppliers for each order, tracks the shipment and bills clients only when each stage is complete.
NetSuite integrates through REST or SOAP web services, RESTlets, SuiteScript, CSV import, marketplace connectors and iPaaS. We compare them by fit, limits and price, list where syncs break and show what a custom integration costs.
Shopify connects to NetSuite through Oracle's NetSuite Connector, Celigo's integration app, other apps or a custom build. We compare what each syncs and costs, list the failure points (variants, tax, discounts, refunds, payouts) and price a custom build.
The best ERP for retail and fashion brands handles size and color matrices, one stock pool across stores, web and wholesale, and clean sync with your POS and marketplaces. We compare seven options by data model, integrations and price.
Anything missing? Send us your question and an engineer will answer, usually within one business day.
Contact usYes. On One Motion ERP we maintain a two-way QuickBooks invoice sync that runs in production, with vendor mapping, tax logic and automatic item ID remapping. Two-way works when each record type has one owner and data flows in a defined direction per field, instead of both systems editing everything.
Both are possible, but they are built differently. Online has a REST API with OAuth 2.0, webhooks and Change Data Capture. Desktop has no cloud REST API: integrations use the Desktop SDK with qbXML, and a web-based system connects through the QuickBooks Web Connector. If you are on Desktop now, we ask whether a move to Online is planned before building.
In our projects: vendors and purchase orders, invoices in both directions, customers matched by QuickBooks ID, and items with automatic ID remapping. The QuickBooks Online API also supports bills, payments and other entities, so the list is set per project in the ownership table you approve.
The sync does not silently overwrite. QuickBooks returns a stale object error when a record changed after we read it. If the field is owned by the ERP, the job re-reads and reapplies only that field. Otherwise the item goes to a review queue that shows the ERP value, the QuickBooks value and the rule that failed.
Intuit documents 500 requests per minute per company and 10 per second per company and app. That is enough for most ERPs if sync is queued and rate-limited, reads only what changed and caches reference data such as accounts and tax codes. Under the Intuit App Partner Program, data-out calls are metered, so efficient reads also keep costs down.
Yes. On One Motion ERP we maintain and extend an existing integration and fix live issues as they surface, from concurrency errors and API failures to wrong quantities and invoice calculations, while new change requests keep shipping.
It depends on the QuickBooks product, how many record types sync and in which direction, how complex your tax and unit rules are, and whether the ERP side exists yet. After we agree the ownership table and review your data, you get a fixed estimate for the work.
A spec, a Figma file or three paragraphs is enough to start.
Cookies on oski.solutions
We'd like to use analytics cookies to understand how the site is used, and marketing cookies to measure our ads. They are off unless you allow them. You can change your choice any time via “Cookie settings” in the footer. Cookie policy