One ERP or Connected Point Solutions? The System Architecture Decision for a Turkish Subsidiary

A finance manager at a foreign-owned manufacturing subsidiary in Türkiye runs a monthly routine that never gets shorter: pull the export file from the accounting package, pull the inventory report from a separate warehouse tool, pull the pipeline numbers from a CRM the sales team picked on its own, and manually stitch the three into one file for the parent company's consolidation deadline. Each tool does its own job well. The problem sits in the gaps between them, and every month it costs a little more time to close.

This is a familiar pattern for subsidiaries that grew tool by tool rather than by design: an accounting package was already in place, a warehouse app was added because stock tracking outgrew it, sales picked its own CRM because the accounting package had no pipeline view. Each addition was a reasonable decision on its own. The result, a few years in, is a stack of disconnected systems and a person whose real job has quietly become manual reconciliation. The question this raises — connect what exists, or consolidate onto one platform — matters more for a Turkish subsidiary than for a purely domestic company, because local compliance requirements (e-Fatura, e-Defter, KDV filings) sit on top of whichever system holds the core financial data.

How does a point-solution stack usually form?

Rarely from a single bad decision. It accumulates from a sequence of reasonable ones:

• The accounting package was inherited or chosen first, mainly for VUK-compliant bookkeeping and e-Fatura/e-Defter output.
• A separate inventory or warehouse tool gets added once stock complexity outgrows the accounting package's basic module.
• Sales adopts its own CRM because pipeline tracking was never part of the original system.
• Point integrations for marketplaces, banking, or field service get bolted on as each need appears.

None of these choices is wrong in isolation. What's missing is a single source of truth that the parent company's reporting, the local tax filings, and daily operations can all rely on without someone manually reconciling three exports every month.

Where does the cost of the gap actually sit?

The visible cost is licensing. The real cost accumulates in three places:

Duplicate data entry. The same customer, the same stock item, the same invoice gets entered separately in more than one system. Beyond the time lost, this is a structural source of error — a record updated in one place can go stale in another with no automatic signal that it happened.

Reconciliation load. At month-end, or whenever a consolidated report is due, someone manually compares outputs across systems. As the business grows, this stops being a task and becomes an unstated full-time responsibility — one that rarely shows up in any budget line as "ERP cost," even though that is what it is.

Decision lag. Management and the parent company's controllers are looking at a table someone assembled by hand, not a live one. That table is usually a day or two behind, which pushes pricing, purchasing, or cash-flow decisions back by the same margin. For a subsidiary reporting into a group consolidation cycle, that lag compounds at each reporting layer.

A decision framework: which structure fits which situation?

Criterion	Point solutions + integration	Single ERP
Number of processes	Few, largely independent	Accounting, inventory, sales, and production tightly linked
Data-sharing frequency	Occasional, a daily batch export is enough	The same data is touched by multiple teams within a day
Growth rate	Slow, processes stay stable	New branches, warehouses, or product lines added often
Reporting / audit need	Simple, derivable from one source	Consistent reporting has to be pulled from multiple sources
Team size	Small enough that one person can track several systems	Different departments work in different screens
HQ consolidation requirement	Local entity reports independently	Parent company needs a consistent, timely feed from the subsidiary
Technical resource	No one available to maintain APIs/integrations long-term	Same

No single row settles the question. But when several rows point toward "single ERP" at once, the ongoing cost of maintaining integrations has usually already exceeded the cost of consolidating.

A practical way to test this without guesswork: track, for one week, how many separate systems the team re-enters the same piece of information into — a customer record, a stock movement, an invoice. If that number stays at a handful of occurrences per week, the current setup is probably still workable. If it has become a daily habit — a sale entered into the CRM, then the accounting package, then the warehouse tool, one at a time — that is a concrete sign that the cost of consolidation has already been earned back.

Why integration is harder than it looks

"We'll just connect the two systems" sounds simple on a whiteboard. In practice, three problems show up:

1. Data model mismatch. A "customer" record in one system rarely maps cleanly onto a "vendor account" in another; someone has to write and continuously maintain the mapping rules.
2. Version dependency. When either system is updated, the integration between them usually needs rework too — this maintenance burden compounds over time rather than staying flat.
3. Ownership ambiguity. When the same piece of data exists in two systems, "which one is correct" needs an explicit rule, or conflicting records accumulate quietly until someone finds them during an audit or a consolidation review.

None of this means integration never works. For standard, one-directional connections — banking feeds, marketplace orders, e-Fatura submission — integration is already a proven pattern. The difficulty shows up specifically where core processes are tightly coupled, as accounting, inventory, and sales usually are; there, an integration often ends up doing the same work twice rather than eliminating it.

Does this matter for a smaller subsidiary too?

The same logic applies at a small scale, just with fewer people involved. If one controller is tracking accounting, inventory, and sales across three separate tools, that person leaving or taking leave means the answer to "which system holds the current number" may leave with them. For a small team, the relevant question is not headcount but how many systems hold the same piece of information. If two or three tools require manual data transfer between them, consolidation is worth evaluating regardless of team size — and for a foreign-owned entity, it also determines how reliably the parent company can get a consistent number out of the subsidiary on demand.

Does everything need to move onto one system at once?

Not necessarily. Some specialized tools — a marketing automation platform, or an industry-specific design application — don't need frequent, two-way data exchange with the core financial system and can stay in place, as long as they draw core reference data (customers, items, prices) from a single source rather than keeping their own copy. What genuinely needs consolidating is the tightly coupled core: customer accounts, stock records, and invoicing. Once that core sits in one system, the remaining specialized tools become simple, low-maintenance, one-directional connections into it rather than parallel sources of truth.

In practice, this means the move doesn't have to happen all at once: the accounting-inventory-sales core is consolidated first, and other tools are either retired or connected to that core afterward, on their own timeline.

How does Birasyo handle this?

Birasyo keeps accounting, inventory, sales, procurement, and manufacturing in a single database — when an invoice is issued, stock, the customer account, and the accounting entry update at the same time, with no separate export or reconciliation step. External connections — banking, e-Fatura, marketplaces (Trendyol, Hepsiburada, Amazon), and data migration from prior accounting software — run through standard, one-directional integration points, which stay low-maintenance because the interface on the other side is fixed and well-defined. For a foreign-owned subsidiary, this also means the parent company's consolidation feed comes from the same core data as the local e-Fatura and e-Defter filings, rather than from a separately maintained export. Management and the group's controllers can review a live table through Reports & Analytics — over 150 pre-built reports plus a drag-and-drop report designer — without asking which system holds the current number.

Summary

• A point-solution stack rarely forms from one bad decision; it accumulates from a sequence of individually reasonable ones, and the real problem is the gap between the tools, not the tools themselves.
• The cost of that gap sits in duplicate data entry, reconciliation load, and decision lag — usually only the license cost gets budgeted, not these three.
• The decision should follow how tightly the processes are coupled: independent, occasionally-shared processes can run on integrated point solutions; tightly coupled processes like accounting-inventory-sales run with less friction on a single system.
• Standard, one-directional connections — banking, e-Fatura, marketplaces — are already a proven integration pattern; the difficulty is specific to tightly coupled core processes.
• For a foreign-owned subsidiary, this decision also determines how consistently and quickly the parent company can pull a reliable number out of the local entity.

Sources: This article reflects general ERP architecture and integration practices and does not constitute compliance or tax advice. Requirements around e-Fatura, e-Defter, and KDV filing formats change; confirm current thresholds and technical specifications with your financial advisor (SMMM) or GİB's official guidance before making a system decision based on compliance needs.