Britixo CRMBritixo CRMEnterprise Help Centre
Ctrl K
Automatic and manual reconciliation · How-to guide

Prevent duplicate Tide reconciliation with transaction idempotency

Detailed client guidance covering prevent duplicate Tide reconciliation with transaction idempotency, with exact eligibility, security, verification and troubleshooting boundaries for the shipped Tide payment and Open Banking controls.

Audience: Administrators and authorised payment operations staffPermission: ReconcileModule v1.0.0
Jump to steps
Where to goTide Payments → Reconciliation
Before you startConfirm the intended tenant, remote account or invoice context, and your Reconcile access. Keep credentials and tokens out of screenshots, tickets and exported evidence. If a previous write may have reached an external service, verify remote state before retrying.

What you’ll accomplish

Detailed client guidance covering prevent duplicate Tide reconciliation with transaction idempotency, with exact eligibility, security, verification and troubleshooting boundaries for the shipped Tide payment and Open Banking controls. This article is intentionally scoped to the behaviour enforced or exposed by the supplied module and does not treat provider marketing features as implemented integration capabilities.

How the workflow fits together

Tide payment instructions, AIS transaction import, exact reconciliation, native invoice payment status and audit evidence are connected but separately verifiable stages. A payment instruction is not proof of receipt; a bank transaction is not a certified invoice payment until it passes the reconciliation gates.

Follow these steps

  1. Open Tide Payments → Reconciliation.
  2. Confirm the intended tenant, invoice/connection/transaction where applicable, and your Reconcile access before continuing.
  3. Confirm the connection and configured lookback window.
  4. Run reconciliation once manually or allow the after-cron automation to run.
  5. For each candidate, verify Booked + Credit + GBP, exact transfer reference and exact current outstanding amount.
  6. Check that the Tide transaction becomes reconciled and that the native invoice payment was recorded exactly once.
  7. Investigate non-matches without weakening the exact-match rules.

Fields and decisions to review

This guide’s focusDetailed client guidance covering prevent duplicate Tide reconciliation with transaction idempotency, with exact eligibility, security, verification and troubleshooting boundaries for the shipped Tide payment and Open Banking controls.
Exact referenceThe incoming bank reference must equal the stored invoice transfer reference.
Exact amountThe incoming credit amount must equal the invoice’s current outstanding balance at match time.
Transaction gateOnly Booked + Credit + GBP transactions are eligible for automatic matching.
IdempotencyThe full Tide transaction identifier is retained and a SHA-256 key protects uniqueness without truncating identity.
LockingA per-connection reconciliation lock prevents overlapping workers from processing the same feed concurrently.
Native paymentAfter a verified match, the module records the result through the native gateway addPayment path so invoice status remains authoritative.
LookbackAutomatic and manual runs operate within the configured 1–90 day lookback, default 7 days.

How to confirm it worked

Reopen the intended invoice, Tide transaction/reconciliation register and audit evidence. Confirm the full Tide transaction identifier where available, exact amount/currency/reference, reconciliation state, native invoice payment and latest timestamps. If the bank-feed state cannot be independently verified, keep the task unresolved and use the supported troubleshooting flow.

Questions clients commonly ask

When is an invoice actually treated as paid?Only when an eligible Tide credit is exactly reconciled and the native gateway payment is recorded; showing transfer instructions is not payment confirmation.
Can staff override a close-but-not-exact bank match?The automatic flow intentionally requires exact eligibility, reference and current outstanding amount. Investigate the bank/reference/invoice state instead of weakening the control.
What should I include in a support case?Include invoice ID, Tide transaction ID if available, reference, amount/currency, booking timestamp, connection status and visible error. Never include access/refresh tokens or private keys.
Does disconnecting remove history?No. Active connection tokens/state can be removed while historical payment, reconciliation and audit evidence is retained.

Technical basis for this guidance

This guide was checked against the supplied module code paths: tide_payments.php; controllers/Tide_payments.php; controllers/Tide_payments_client.php; models/Tide_payments_model.php; helpers/tide_payments_helper.php; libraries/Tide_gateway.php; libraries/Tide_open_banking_client.php; libraries/Tide_partner_client.php; views/admin; views/client/pay.php; install.php; config/routes.php. It documents shipped behaviour, validation, routes and evidence controls; it does not claim successful live provider network calls from offline inspection.

Controls, checks and common mistakes

  • Work in the intended tenant and remote accounting/business context.
  • Do not paste credentials, access tokens, refresh tokens or private keys into tickets or notes.
  • Do not bypass a missing mapping, validation error, permission gate, duplicate check or remote-verification requirement.
  • Do not repeat a non-idempotent write until you know whether the previous request reached the remote service.
  • Keep native record, remote evidence and audit/history state aligned before closing the task.
Provider and accounting boundaryAutomatic and manual runs operate within the configured 1–90 day lookback, default 7 days.
Browse connected topics: Automatic and manual reconciliation Tide Payments Accounting & Bookkeeping
Understand the Tide reconciliation lookback windowUnderstand the per-connection Tide reconciliation lockAccounting & Bookkeeping guides