Accounting Integration Hub (1C / Soliq)

What architectural challenge is being solved

Accounting and tax integration hub is an architectural challenge before it is a software feature. The bank needs to connect accounting and tax integration hub across existing systems without creating another fragile island. The objective is data flow between 1C, the bank and Soliq: a stable integration and data contour that supports business processes while respecting the limits of legacy core banking.

The architectural baseline has to be honest. If the current flow depends on manual exports, undocumented formats or personal knowledge of a few employees, the roadmap must show it openly.

What systems, data flows and teams are involved

The involved landscape usually includes core banking, CRM, DWH, ESB or API gateway, document flows, accounting systems, external registries, digital channels and operations teams. Business, IT, risk, compliance and branch networks all touch the process. If one participant is ignored, the architecture may look clean on a diagram and fail at the first real exception.

Good architecture also defines what will not be integrated at the first stage. This protects the bank from endless scope expansion and keeps the first contour governable.

Typical architectural mistakes

Typical mistakes are building direct point-to-point integrations, treating Excel as a permanent integration layer, ignoring master data ownership and designing only for the happy path. Another frequent mistake is assuming that a new platform will solve governance. It will not. Bad identifiers, unclear statuses and manual approvals simply move to a more expensive screen.

Architecture should not punish the bank for having legacy systems. The task is to create a controlled surrounding ecosystem where the core remains stable and the business gains flexibility.

Possible architectural approaches

Possible approaches include an integration hub, API layer, event-driven triggers, controlled batch exchange, canonical data models and reconciliation routines. The correct choice depends on data freshness, regulatory constraints, operational criticality and the maturity of existing systems. Real-time is not always better; unmanaged real-time can spread bad data faster.

Monitoring and reconciliation are not optional. Without them, integration works only during demonstrations and quietly fails in daily operations.

How to avoid unnecessary core replacement

Unnecessary core replacement is avoided by separating systems of record from orchestration layers. The core remains the authoritative ledger where it should be, while the surrounding layer handles workflow, validation, notifications, analytics and client-facing journeys. This is usually faster, safer and more realistic for banks with heavy legacy dependencies.

The target state should separate strategic direction from immediate build scope. A bank can know where it is going without trying to build the whole map in the first release.

Risks, dependencies and constraints

The main risks are poor data quality, unclear ownership, weak monitoring, regulatory constraints, vendor lock-in and underestimated branch reality. Dependencies include API availability, batch windows, security rules, consent management and audit requirements. Architecture must explicitly document what is verified, what is inferred and what requires manual confirmation.

What a phased roadmap should look like

A phased roadmap should start with a baseline of systems, data sources, pain points and target flows. The next phase designs the minimum integration contour, then launches a pilot with reconciliation and monitoring. Only after evidence is collected should the bank expand scope, add channels and automate more exceptions. Scale must follow proof, not enthusiasm.

The roadmap should leave room for regulation, security review, procurement and branch adoption. These are not delays; they are part of the real architecture of a bank.

Practical next step

The practical next step is to prepare an architectural assessment: integration map, data ownership, dependencies, target state and phased roadmap. SamaraliSoft can help the bank design the contour around existing systems and define requirements before vendors, budgets and timelines harden into expensive assumptions.