Booking System Accounting Integration: How to Connect Bookings to Your Accounts

Booking system accounting integration should carry booking invoices and money movements into your accounts without retyping them. A CSV import can be enough if somebody checks each batch and handles later changes. If deposits, cancellations and refunds occur regularly, compare the available connectors before commissioning a custom link. In either case, decide who records each receipt and how to correct mistakes.

Is a CSV export enough, or do you need a live integration?

Use CSV for controlled, occasional imports where somebody can verify the result. Use a supported connector for regular updates, provided it transfers the events you actually need. A custom connection is justified when neither route handles the booking rules or corrections; it also leaves you responsible for its error handling. Whether to keep, extend or replace the booking software itself is a separate question, covered in the guide to choosing between custom and SaaS booking systems.

These are different accounting routes, not interchangeable files. Xero's UK invoice import guidance, checked on 4 November 2026, says customer invoices arrive as drafts, recommends no more than 500 items per file, and rejects an invoice whose number already exists in Xero. Invoice lines sharing a number belong to one invoice. Xero's credit-note instructions provide a separate CSV import that also creates drafts. Check each batch and approve only after comparing its lines and VAT.

Intuit's UK QuickBooks Online guidance allows up to 1,000 rows and 100 invoices in an invoice import. That route does not accept negative charges or credit notes; credit notes have their own import, with Intuit advising no more than 100 at once. Check Custom transaction numbers before relying on your source invoice numbers. Keep a register of each batch, then re-import only the corrected rejected rows, never the whole file again. Neither invoice import records the customer's payment: receipts, refunds and payouts need their own entry or matching.

An export from the accounts is an audit snapshot, not a restorable backup. CSV files cannot rebuild all settings, record relationships or change history. Ask the accounting provider which recovery or backup options your subscription offers, and check them separately. Secure the exports: the ICO's storage guidance says personal data should not be kept longer than needed. Limit access, store working files securely, then delete temporary copies when the check is complete, subject to record-retention duties.

How card payments are taken is covered in the booking payment options comparison. The accounting question is whether those receipts reach the books once, and whether a bank settlement is matched to them rather than counted as fresh sales income. The broader development choices for connecting business software through an API are separate from the bookkeeping rules.

What data should a booking send to accounting software?

Send the information needed to create or match financial records, rather than copying the entire booking profile. Keep a stable booking reference, customer identity, service lines and their VAT treatment. Give each payment, refund or adjustment its own source reference and store the destination IDs so later changes can find the right record.

• Booking and invoice: Source booking and financial-document IDs, invoice number, customer, invoice date, due date, service lines, amounts, currency and the correct income accounts. An appointment date is not automatically the invoice date.
• Customer: Match contacts separately from bookings using the available identifiers and reviewed details. Check existing contacts before allowing a connector to create another one; identical names do not prove two people are the same.
• Money: Unique references, actual transaction dates, amounts and status for deposits, final payments, refunds, fees and adjustments. Link a customer receipt to its invoice or agreed prepayment record.
• Integration: Destination company, accounting document IDs, last confirmed transfer and unresolved error. Store these in an access-controlled log, not customer-facing invoice text.

Review tax per line, not only the invoice's gross total, especially for services with different VAT rates. Compare the source line amounts and VAT codes with those calculated in the accounts. Check refunds in the same way: Checkfront's QuickBooks guidance warns that mixed-tax refunds can produce amounts that need a manual accounting correction.

Do not send private appointment notes or marketing preferences merely because they exist. The ICO's small-business guidance supports transferring only personal data needed for the purpose. Check both the export columns and who can read the sync log; remove surplus fields before enabling transfers.

How should deposits, final payments and refunds appear?

A booking is not necessarily an invoice, and a deposit is not necessarily earned income. A payment towards a future service, a refundable security deposit and a forfeited deposit can require different entries. Agree the income, liability and VAT treatment with the accountant before allowing booking events to post automatically.

HMRC's advance-payment guidance explains that an advance payment towards a service may create a VAT tax point before the appointment: the earlier of the VAT invoice date and the date the payment is received. A payment against an invoice already issued must not be taxed a second time. Its treatment differs from a returnable security deposit. HMRC's security-deposit guidance addresses deposits held against loss or damage, while its guidance on retained booking deposits explains why keeping money after cancellation does not necessarily remove VAT. Ask the accountant to review the contract and circumstances, rather than treating every deposit alike.

• Booking accepted: Save the booking reference. Only issue an invoice under the agreed rule; check it belongs to the right contact and has the correct service lines.
• Deposit or balance received: Record the genuine receipt against the invoice or approved prepayment arrangement. Check the remaining amount due and avoid treating advance cash automatically as revenue already earned.
• Cancellation or refund: Check whether money was returned, whether an invoice credit is needed, and which invoice any credit was applied to, in case an automatic-credit setting chose a different one. Record the refund and correct the sale through supported accounting actions, then verify the customer's balance and VAT lines.
• Other exceptions: A no-show fee may start in the booking tool, but whether it is chargeable and taxable needs agreement. Chargebacks, disputes and failed settlements usually start with the payment provider; check its notice against the accounts rather than inventing a refund in the booking system.

For VAT-registered businesses using several pieces of software to maintain the electronic account, HMRC's Making Tax Digital notice accepts CSV imports and exports as digital links. Manually retyping figures between those parts of the software chain is not a digital link. Confirm with the accountant which systems form the VAT record and check that the transferred VAT lines reconcile.

Can a booking system connect to Xero or QuickBooks?

Yes, depending on the booking product and its current integrations. Bookeo documents accounting connections and an export alternative. A developer can also use the accounting APIs, but the availability of an API says nothing about whether cancellations or historic payments are handled correctly.

Ask what starts syncing at authorisation, whether sending can be paused, and where changes must be made before connecting. Acuity's accounting help, checked on 4 November 2026, says its QuickBooks connection starts syncing clients and appointments when set up. It also says new Acuity-to-Xero connections are unavailable. Do not assume a new link starts in a harmless, inactive state.

Checkfront documents a one-way QuickBooks connection. Its separate invoice editing guidance says voided bookings do not sync to QuickBooks and need manual invoice correction. Its payment guidance says transactions from before integration activation are not sent automatically. Record these exclusions in the operating procedure, and verify that corrected invoices match the booking before closing the exception.

Calendar links are not accounting links: synchronising booking times with Google Calendar does not account for a payment. Decide whether the connector or accounting system owns customer receipts. If the connector creates a payment, the bank feed should match its later settlement, not enter another receipt for the same sale.

For example, if an invoice is already marked paid by the connector, a bank-feed rule must not record the same card payment as new income. Match the provider settlement to the recorded receipt or clearing account, allowing for fees and grouped payouts. A payout is often several days of receipts minus fees, refunds and chargebacks, so record the gross receipts and the fees separately and match the net payout through the clearing account. Check the payment report afterwards. If the rule has created a second receipt, disable it and have the duplicate corrected through the accounts before resuming imports; do not remove reconciled entries without review.

How do you stop duplicate invoices when the integration retries?

Give each intended financial document a stable reference and save its accounting ID. A database uniqueness rule blocks duplicate operation rows, but it does not stop two workers from sending the same API request. Claim each pending operation atomically before sending: use a lock or a conditional status change that only one worker can win.

Xero's developer guidance, checked on 4 November 2026, requires reuse of the same Idempotency-Key for retries of an unchanged request. Keys over 128 characters are rejected; Xero retains protection for six minutes, so reuse after expiry is unsafe. Intuit's QuickBooks Online developer guidance uses the requestid query parameter, unique within the company, with a maximum of 50 characters for ordinary operations and 36 for batch operations. Individual batch IDs are limited to 10 characters when a request ID is also specified. For a batch retry, the batch IDs must also match. The documentation checked does not establish a QuickBooks retention period; do not assume protection lasts indefinitely.

• Step 1: Claim. Reserve a unique operation for the source document, its version, the action (create, amend or credit) and the destination company. Change its pending status atomically before the API call, so a second worker cannot send it. Check the claim result; on conflict, stop that worker and leave the original operation in control. Give each claim an expiry time, and before reclaiming an expired one, check the accounting system for a record the first worker may already have created.
• Step 2: Send and record. Persist the provider retry key before sending, reuse it for the same payload, then save the returned accounting ID. Read the invoice back to check the reference, contact and totals. If a field differs, pause further writes and investigate.
• Step 3: Resolve a timeout. Search for the destination record by the stored reference, not by customer, amount and date alone, and compare it with the source. Only one exact match on that reference can close the operation. An empty or uncertain result does not prove the write failed: keep it unresolved and require a later read or human review before another creation attempt.
• Step 4: Correct safely. Make a supported amendment or credit instead of creating the invoice again. If it is paid, approved or reconciled, stop automation and agree the adjustment with the bookkeeper. Never delete an accounting record merely to clear a retry error.

Respect API limits while resolving errors. Xero's API guidance says a rate-limit response provides a Retry-After header; keep the operation queued until retry is permitted. Check the queue afterwards for one confirmed destination ID, rather than marking throttled attempts successful.

What is the safe order for connecting the systems?

Do not authorise the connector until you know whether it starts sending immediately and whether it can pause. First agree the bookkeeping rules and how to recover from an incorrect posting. Test in an isolated environment where one exists; a production test needs tighter control.

• Step 1: Preserve and verify. Export dated booking transactions and accounting reports, then check the files open and the period totals agree. Treat them as evidence, not backups. Confirm the accounting provider's own restore or recovery options separately; if the provider offers no restore, agree a correction and reconciliation process with the accountant before enabling writes.
• Step 2: Agree ownership and cutover. Have the accountant approve deposit rules, VAT mapping and which component posts customer payments. Identify the cutover date and all invoices already imported. Include receipts already entered manually, because an invoice-only exclusion list will not prevent duplicate cash. Check the exclusions against the live ledger and the booking report for the same period; if they cannot be made reliable, continue reviewed imports.
• Step 3: Check before authorisation. Establish exactly which records sync on connection, whether invoices are sent to customers, and how to pause outgoing activity. Confirm the accounting organisation and permissions. If the connector cannot pause and would write unreviewed records, do not connect it yet.
• Step 4: Test without customer money. In a sandbox, cover unpaid bookings, deposits, refunds, cancellations and repeated events. Compare document IDs, VAT per line and balances after each action. Without a test mode, obtain the accountant's agreement before any tightly controlled production test, use a designated test customer and turn off customer emails where supported. If that cannot be done safely, do not run the test. A sandbox pass does not prove the live VAT codes, accounts or email settings, so compare those with the live organisation before the first live batch.
• Step 5: Start a reviewed batch. Where supported, leave invoices in draft and check each against the source before allowing routine syncing. Stop on an unexpected record. To roll back, pause the job queue first, examine queued and in-flight writes, record the exact cutover point and list documents that must not be re-imported manually. Disconnecting alone cannot undo a request already sent.
• Step 6: Reconcile before expanding. Compare the booking payments report with payments entered in the accounts for the same transaction dates, currency and status; investigate each difference. Match the payment-provider settlement report to the bank for settlement dates, allowing for fees and settlement delays. Unpaid invoices belong in the receivables comparison, not the paid-receipts total. If a match fails, keep the connector paused while corrections are reviewed.

How can you tell whether the sync is still correct?

Someone needs to own the exception queue. Alert them when an expected transfer is missing, an error remains unresolved, the backlog grows or the accounting connection expires. A connection-success message is not proof that the right invoice was created; compare accounting IDs and financial records instead.

Keep a restricted log with source and destination references, the action attempted and its confirmed result. Grant the connector only the permissions it needs, keep its credentials out of the code and revoke them when it is retired. Review outstanding operations after API throttling rather than hammering the provider with immediate retries. Check customer duplicates separately. Any manual accounting edit should be marked for review against the booking system, and unresolved differences should block automatic overwrites until the correct source is agreed.

Define an expected transfer from a real booking event rather than assuming that silence means success. Compare the queue with the booking events report, assign each unresolved exception to a named person and record the outcome when it is fixed. If the connection stops authorising writes, pause the queue and reauthorise only after checking which operations remain uncertain. Keep the last successful transfer reference so recovery does not silently skip or replay bookings.

For ongoing checks, reconcile booking receipts against accounting payments on a transaction-date basis, then reconcile settlement batches against bank deposits on a settlement-date basis. Expected differences include unpaid invoices, processing fees and transactions that cross the reporting cutoff. Check those against the original records before changing an invoice or payment entry.

Next step: CSV, connector or custom

Use reviewed CSV imports if they meet your needs. If ongoing transfers are necessary, you can hire me to connect your booking system to your accounts after agreeing the mapping and recovery process. Before switching on booking system accounting integration for every booking, run one batch through the reconciliation above and clear every difference.