Accounting Software Integration: Methods and Pitfalls

Accounting software integration is built one of three ways: through the REST API of a cloud accounting product, through the service layer or a staging database of an on-premise system, or — when neither is available — through scheduled file transfer (XML/CSV). The method changes, the data does not: orders, customers and payments flow from your website into accounting, while stock, prices and invoice references flow back. And the thing that decides how long the project takes is not the API documentation; it is how carefully the two sides are mapped to each other.

Which data flows in which direction?

The first question in an accounting integration is not “which product are we connecting” but “where is each record born”. Technically this is an API integration job; contractually, it is these five flows:

• Order → sales invoice: an order created on the site becomes an invoice in accounting. Line items, discounts, tax rates and shipping fees all have to land on the right rows.
• Customer → account record: a new customer is opened as an account. To avoid creating a second record for the same buyer, you need a matching rule based on tax number or e-mail.
• Stock and price → website: current stock and list prices are pushed to the site. Decide up front which side is the single source of truth.
• Payment → accounting: card, bank transfer or cash-on-delivery payments are matched to the right invoice. Refunds and partial refunds are a separate flow and cannot be postponed.
• Invoice number and document → website: the reference is written back so the customer can see the invoice in their own account.

You may not need all five. At low volume, automating only “order → invoice” and managing stock by hand is a legitimate decision. What matters is starting out knowing which direction is not automated.

Three methods: cloud API, on-premise, file transfer

Cloud accounting products expose a modern REST API: you authenticate with a token, post invoices and account records as JSON, and the documentation tells you how many requests per minute you are allowed. This is the fastest integration to stand up — no server, no VPN, no extra licence.

On-premise systems are a different story. Their service layer is often a separately licensed module, and what is available differs by version — so confirm version and module details with your vendor before development starts. If there is no service layer, the second option is the staging-database approach: the integration writes into a queue table and the product’s own import tool reads from it. Writing directly into live accounting tables is the one thing you should not do; it breaks accounting rules and record integrity, and it puts you outside vendor support.

The third method is scheduled file transfer: the integration produces XML or CSV at intervals and accounting imports it. It sounds primitive, yet it is still common in high-volume companies that reconcile daily. The trade-off is that nothing is real time — stock goes stale during the day. You will face the same choice on the e-invoicing side; our e-invoice integration article compares the portal, integrator and direct options in detail.

The schedule of an integration project is set by mapping, not by API documentation. If product codes, units, tax rates, discounts and payment types do not speak the same language on both sides, every order gets corrected by hand. If the connection takes a week, mapping and testing usually take two.

How to structure the cloud API flow

The critical rule with a cloud API is not to send the invoice at the moment of checkout. If accounting is under maintenance or the rate limit is exhausted, the call fails and the order ends up without an invoice. The right shape is: closing an order creates a queue record, a worker processes the queue, and failed requests are retried. The key that prevents double invoicing lives in that same flow:

// Runs from a queue, not at checkout time.
// The idempotency key prevents the same order being invoiced twice.
async function sendInvoice(order: Order) {
  const res = await fetch(BASE_URL + '/sales_invoices', {
    method: 'POST',
    headers: {
      Authorization: 'Bearer ' + (await getAccessToken()),
      'Content-Type': 'application/json',
      'Idempotency-Key': 'order-' + order.id,
    },
    body: JSON.stringify({
      contact_id: order.accountingContactId, // matched account record
      issue_date: order.paidAt.slice(0, 10),
      items: order.lines.map((line) => ({
        product_id: line.accountingProductId, // matched product code
        quantity: line.qty,
        unit_price: line.unitPriceExclVat, // unit price excluding tax
        vat_rate: line.vatRate,
      })),
    }),
  });

  // 429 and 5xx are not permanent failures: keep it queued and retry.
  if (res.status === 429 || res.status >= 500) {
    throw new RetryableError('Accounting API temporary error: ' + res.status);
  }

  const invoice = await res.json();
  await saveInvoiceRef(order.id, invoice.id, invoice.number);
}

Two details bite most projects later. First, token renewal: access tokens live for hours, and if you do not write the refresh flow up front the integration quietly stops one night. Second, the direction of notifications: many accounting products do not send you webhooks, so you have to ask — poll — whether an invoice was issued or a payment was matched. Pick the polling interval against the rate limit.

What to prepare for with on-premise systems

With on-premise accounting, half the work is access and permissions. These items have to be settled before development starts, otherwise the team waits for weeks:

• Server access: restricted ports over VPN or a static IP, and who signs off on it.
• Test environment: a copy of the live database. An integration with no test environment gets tested in production, which means wrong invoices.
• Licence and module confirmation: is the service layer available in your version, does it need an extra licence.
• Permission model: which user the integration acts as and which records it may create. Issuing invoices and creating account records are governed separately.
• Failure channel: who sees it when a record cannot be transferred. A silently growing error queue becomes a month-end reconciliation nightmare.

Most of these are already defined in companies running an ERP. If you are still deciding whether your accounting product should grow into one, what an ERP is and ERP for small businesses cover that decision separately.

Five classic mistakes that break the integration

• No single source of truth: stock is decremented both on the site and in accounting, and within days the two no longer agree.
• Incomplete tax and unit mapping: invoices issued with the wrong tax rate need correcting, which adds work for the accounting team.
• Postponing cancellations and refunds: a refund always arrives in the first week after go-live, and the stranded invoice is fixed by hand.
• Calling the API directly with no queue and no retry: when accounting goes into maintenance, that hour’s orders end up without invoices.
• No audit trail: without a screen showing which order became which invoice, reconciliation goes back to being manual and the time you saved is lost.

Four of these share one root cause: integration is treated as data transfer when it is really reconciliation. You see the same discipline in shipping integration and marketplace integration projects; accounting is the last link in that chain, and because the mistakes touch money, it is the most expensive one.

How to estimate time and cost

The price of an accounting integration is not a single line; it is the sum of three. The development side is estimated in person-days, and it breaks down as follows:

• Discovery and mapping: which field corresponds to what, where each record is born. The shortest yet most decisive phase of the project.
• Development: including the queue, retries, audit trail and error screen. There is a real gap between a simple one-way flow and a two-way flow with stock feedback.
• Testing: with real data, including refund and cancellation scenarios. Without a test environment this stretches.
• Go-live and first-month monitoring: the integration is watched until the first reconciliation closes.
• Items outside software: the accounting product’s module or licence fee, plus any integrator subscription.

How a person-day estimate is built, and what to compare when quotes land on your desk, is covered in custom software cost. The shortcut: if “integration” is a single line in the quote, the scope has not been discussed yet — each flow and its direction should be itemised.

Conclusion

Accounting software integration is moderate in technical difficulty and high in operational sensitivity: your product decides the connection method, while mapping and reconciliation discipline decide the schedule. A cloud API gets you moving fast; an on-premise system means solving access, licensing and the test environment first. In both cases, an integration built without a queue, retries and an audit trail falls back to manual fixing at the first hiccup. If you would like a roadmap for connecting your own system to accounting, take a look at our corporate solutions service or request a quote and we will define the scope together.