Business Systems Integration: A Practical Guide to Connecting CRM, Accounting and E-commerce
Most growing businesses end up running four or five separate systems: a CRM for sales, accounting software for invoices, an online store, and something for stock, fulfillment or scheduling. Each works well on its own. The trouble sits in the gaps between them, where a person copies an order from one screen into another.
Business systems integration means making those systems exchange data automatically, by rules you have agreed in advance. It can be done with a built-in connector, an integration platform, or custom software development against each system's API.
This guide covers the options, the decisions that matter more than the tooling, and how to scope a first integration that is small enough to finish.
What disconnected systems really cost
The visible cost is re-keying: staff time spent typing the same customer, order or invoice into a second system. The less visible cost is mismatched records. Once the same customer exists in three places, the three copies drift apart. An address is updated in the store but not in accounting. An invoice is marked paid in the ledger while the CRM still shows it as overdue, and a salesperson chases a customer who has already paid.
Mismatches also undermine reporting. If revenue in the store, the CRM and the ledger do not agree, someone has to reconcile them before anyone can trust the numbers. This cost grows with volume, which is why integration usually becomes urgent during growth rather than at the start.
Four ways to connect your systems
Native connectors
Many products include ready-made connections to popular partner products, switched on from a settings screen. This is usually the quickest route and the vendor maintains it. The limit is that it does what the vendor decided: fixed fields, a fixed direction and little control over edge cases. Always check this option first.
Integration platforms
These third-party tools sit between your systems and let you assemble flows from prebuilt connectors: when this happens in system A, do that in system B. They suit simple, lower-volume flows and can be managed without developers. Check how the pricing scales with the volume you expect, and be aware that complicated logic built in a visual tool becomes hard to test and maintain.
Custom API integration
An API is the interface a system offers for other software to read and write its data. A custom integration is a small application written for your business that talks to each system's API and applies your rules. It makes sense when those rules are specific to you, volumes are high, or mistakes are expensive. You own it, which also means maintaining it as the vendors change their APIs.
File exchange as a last resort
Exporting a spreadsheet or CSV file from one system and importing it into another is sometimes the only option with older software that has no API. It is slow, breaks when a column changes, and tends to fail silently. Treat it as a stopgap, not a design.
Most businesses end up with a mixture: native connectors where they fit, and custom work for the one or two flows that carry the business.
Decide the source of truth for each kind of data
Before choosing a tool, decide which system owns each type of data. The source of truth is the one system where a given record is created and edited; every other system receives a copy. A typical split is that the CRM owns contacts and deals, accounting owns invoices, payments and tax, the store owns orders, and the operations or inventory system owns stock levels. Your split may differ. What matters is that it is written down and each kind of data has exactly one owner.
This makes most flows one-way, and one-way flows are far easier to build and to debug. Two-way sync of the same field forces you to decide what happens when both sides change it before the next sync, and no rule suits every case. Also agree on a shared identifier, such as storing the accounting customer ID on the CRM record, so records are matched by ID and not by name or email address, which change and collide.
Real-time or scheduled sync
Real-time integration usually relies on webhooks: the source system sends a message to your integration the moment something happens. Scheduled sync runs at intervals, such as every fifteen minutes or once a night, and collects everything that changed since the last run.
Choose by asking how stale the data can be before it causes a problem. Stock levels on a busy store need to be close to live or you will oversell. Posting yesterday's sales to the ledger can happen overnight. Scheduled sync is simpler and easier to rerun after a failure, so do not pay for real-time where nobody needs it. Many dependable integrations use both: webhooks for speed, plus a scheduled reconciliation that catches anything the webhooks missed.
Plan for failure: error handling and monitoring
Every integration fails sometimes. A system is down for maintenance, a required field is empty, a request limit is reached. What matters is whether the failure is noticed and recoverable. Vendor documentation is candid about this. Stripe's webhook documentation says it retries failed deliveries for up to three days in live mode, does not guarantee that events arrive in the order they were generated, and that an endpoint may occasionally receive the same event more than once. Shopify's documentation likewise warns that an app might receive the same webhook more than once, for example after a network timeout or a retry.
The practical consequence is that an integration must be safe to run twice. Developers call this idempotency: receiving the same order message twice must not create two invoices. Beyond that, ask for automatic retries for temporary faults, a holding area where records that keep failing wait for a person to review them, a searchable log, and alerts that go to a named person. A simple daily comparison, such as orders in the store against invoices created, catches the failures that raise no error at all.
Keep credentials secure
An integration holds keys to your financial and customer data. Where a system supports it, connect using OAuth 2.0 and not a staff member's username and password. The OAuth 2.0 standard was designed so that an application can obtain limited access without being given the owner's password, using tokens with a specific scope and lifetime.
Give each integration its own credentials with only the permissions it needs; if it only reads orders, it should not be able to delete them. The OWASP Secrets Management Cheat Sheet recommends applying least privilege, rotating secrets regularly so that a stolen credential only works for a short time, and auditing who requested and used each secret. Keys should never live in source code, spreadsheets or email. For the wider picture, see our web application security checklist.
Common mistakes, and when not to integrate
- Automating a messy process. Duplicates and inconsistent records are copied faster, not fixed. Clean the data first.
- Choosing two-way sync by default when one-way would do.
- Testing only the simple case. Refunds, partial shipments, cancellations and edited orders are where integrations break.
- Ignoring history. Decide whether existing records will be linked or only new ones.
- Having no owner after launch, so alerts arrive and nobody reads them.
Integration is not always worth it. If a flow involves a handful of records a week, or the process itself is about to change, manual entry with a clear checklist may be cheaper than building and maintaining a connection.
What to do next: scope a first integration
Pick one flow with obvious daily pain, for example paid online orders becoming invoices in accounting. Then write a one-page specification that answers five questions:
- What event triggers the flow, and in which system?
- Which fields move, and how does each one map, including tax, currency and discounts?
- Which system is the source of truth, and which ID links the records?
- How fresh does the data need to be?
- What happens when a record fails, and who is told?
Confirm that your subscription to each system includes API access and what request limits apply. Build against test accounts using real examples, then run the integration alongside the manual process for a while and compare results before switching the manual step off.
Conclusion
Connecting business systems is less about tools than about decisions: which system owns each kind of data, how fresh it must be, and what happens when something fails. Start with the simplest approach that meets the need, keep flows one-way where you can, protect the credentials, and make failures visible.
If you have a first flow in mind and want a second opinion on the approach or the effort involved, you can request a quote and describe the systems you need to connect.