When the connector is working and exceptions still remain

This page is not an argument against connectors. A2X, Bookkeep, Synder and native integrations are often the right solution for standard workflows, and if one already produces a clean close, the correct advice is to keep it and stop reading here.

What follows is about the narrower case where the connector is configured correctly, posting is accurate, and a recurring exception population still survives every close.

What connectors are built to do

Summarize e-commerce activity and post it correctly into the ledger on a repeatable basis. For a single channel with one processor, that is usually the whole job, and it is done well.

Where residual exceptions tend to appear

• Several independent sources.A connector generally owns one relationship. When Shopify, a second gateway, a marketplace, wholesale invoicing and the bank all have to agree, nothing owns the join between them.
• Reconstruction rather than posting.Proving a bundled deposit is fully explained by its components is a different operation from posting summarized activity.
• Cross-period adjustments.Refunds and disputes landing in different periods from their original sale.
• Client-specific rulesthat standard configuration cannot express, which is not a defect so much as the limit of a general-purpose tool.
• Non-standard channelssuch as retail POS, subscriptions or B2B portals joining the same account structure.

A layer, not a replacement

The sensible architecture keeps the connector doing what it does well and adds deterministic matching only where the residual justifies it. Nothing gets ripped out. The custom layer reconciles across sources, reconstructs bundled settlements, and routes what remains into a reason-coded queue for review.

When standard software is enough

Standard connectors are often the right solution for standard workflows. If the connector posts activity correctly and the clearing account returns to zero without investigation, there is nothing here worth building. Keep the software you have.

When custom automation may be justified

The case for a custom reconciliation layer depends on recurrence, not on frustration. It is worth looking at when the same exception patterns return every close, several sources have to agree before the balance resolves, and meaningful staff time goes into work that follows repeatable rules.

If you want a structured answer rather than an opinion, the Fit Score scores one workflow against recurrence, effort, source complexity, rule repeatability and portfolio reuse. It runs in your browser and takes a couple of minutes.