Manufacturing SMEs and industrial companies
Factories in carpet, machinery, textile or food production running work orders, recipes, scrap and cost tracking in Excel, and wanting to close the gap between production and accounting.
ERP software designed around your processes, bringing your entire operation — from production to finance — onto a single backbone. Where the off-the-shelf package falls short, we build a system that fits your factory exactly.
Prepared by Pan Innovation House, a software company based in Gaziantep, Türkiye · Last reviewed:
ERP (Enterprise Resource Planning) is software that unifies a company's production, inventory, purchasing, costing, finance, sales and shipping processes on a single data backbone. With one source of truth, every department sees the same stock, the same cost and the same order status; information flows inside the system, not between spreadsheets. Set up properly, ERP is not an accounting tool — it is the factory's real-time decision centre.
Off-the-shelf ERP packages are a quick start for standard processes; but in carpet, machinery, textile or food production, recipes, scrap rates, subcontracting relationships and cost calculations rarely fit the package. At that point companies either give up on the software and go back to Excel, or force their processes to fit the tool. Custom ERP software reverses that balance: the software adapts to the way you work, not the other way round.
At Pan Innovation House, rather than writing an ERP from scratch as a monolith, we build it as an API-first, modular architecture that talks to your existing systems. Accounting can stay in Logo (a widely used Turkish ERP), SAP or Mikro, while we develop the production, planning and costing layer specifically for you. The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences. Deliveries go through a review step before they go live, and the maintenance scope and response times are defined in the contract.
Factories in carpet, machinery, textile or food production running work orders, recipes, scrap and cost tracking in Excel, and wanting to close the gap between production and accounting.
Companies using Logo or a similar ERP while running half their processes outside it. Firms whose subcontracting, tiered costing or bespoke planning needs push past the package's limits.
Businesses that need shipping, customs documentation, currency-based costing and multi-warehouse tracking in one system, and want to see the export operation on the same backbone as sales and production.
Management teams finding that as order volumes grow, tracking stock, planning and cash flow by eye has become impossible — and wanting to move to a data-driven, scalable foundation.
Work orders opened against sales orders or stock forecasts, operation and station tracking, bill-of-materials (BOM) based production, shift and scrap recording. Data entered on the shop floor feeds planning in real time.
Material requirements planning calculates which raw material is needed, when and in what quantity; purchasing suggestions, capacity and delivery scheduling. Which order is waiting on what is visible on a single screen.
Multi-warehouse stock, minimum/critical level alerts, batch and serial number traceability, goods in/out via barcode/RFID. The gap between actual stock and recorded stock closes.
True production cost including raw materials, labour and overheads; profitability by order, product or customer. You see in hard numbers which jobs actually make money.
Customer/supplier accounts, receivables and payments, cheques and notes, banking and cash flow projections. E-invoices and e-dispatch notes are managed from within the ERP through your private integrator's API (an integrator approved by GİB, the Turkish Revenue Administration), or through direct GİB integration where you are authorised for it.
The flow from sales order to dispatch, partial deliveries, dispatch notes and customs documentation; currency and delivery-date tracking for exports. The status of a customer order is visible at every stage.
Two-way integration with your existing accounting system through the route its version supports (API, service layer or an approved import); role-based permissions, audit trails and live management dashboards. Duplicate data entry disappears.
If you run operations in Türkiye, the natural first option is an off-the-shelf ERP: a local package such as Logo, Mikro or Netsis (Turkish ERP products), or an international one such as SAP Business One or Microsoft Dynamics. For many businesses that is the right place to start. We do not sell ERP packages: if you are looking for a package licence, go to the product's authorised partner for the licence, implementation and official support. What we usually recommend is not replacing your ERP but building a custom layer alongside it for the processes that do not fit it. The table below sets out four routes side by side; if an off-the-shelf package will do, we say so plainly during discovery.
Three questions usually settle it: is the problem in the whole of your current system or in a few processes; are those processes standard for your industry or specific to you; and which system will carry the accounting and statutory e-document workload?
| Route | Right when | Where it struggles | Cost structure |
|---|---|---|---|
| An off-the-shelf ERP: buying your first or staying with your current one (Logo, Mikro, Netsis, SAP Business One, etc.) | You have no ERP yet, or your current package does the job; your processes are close to industry standard; accounting, e-invoicing and statutory reporting come first; the package's standard modules can cover most of what you need. | When a shop-floor, warehouse, quality or costing flow specific to you does not fit the package, the work drifts back to spreadsheets and manual entry. Whether a need is met by a standard module, an add-on or customisation varies by product and version; ask your vendor or implementation partner. | Licence or subscription, implementation and, for perpetual licences, annual maintenance; customisation is usually priced separately. The model varies by product and partner. |
| Keeping your ERP, or your accounting software, and adding a custom layer alongside it | Your ERP, or your accounting software if that is all you have, handles accounting and e-documents well; the problem lies in a few operational processes (shop floor, warehouse, quality, traceability). You want to fix that area without replacing the existing system. | The integration between the two systems is the heart of the job. The connection route your existing system exposes (API, service layer or an approved import) varies by product, version and licence, and should be confirmed in writing during discovery. If you do not decide up front which system holds the master record for each piece of data, duplicate records follow. | Your existing ERP licence and maintenance continue; the layer is a project fee plus a maintenance agreement, and new investment is focused on the problem area. Whether the ERP side needs an extra licence, user or module for the integration varies by product and version; ask your vendor. Hosting and infrastructure are a separate item. |
| A custom ERP for your whole operation | The problem is in the package's core: your competitive edge lies in the process itself and no package fits your basic flow. The second route fixes a few processes; this one moves your whole operational backbone into a custom system, and accounting can stay in a package if you prefer. You are prepared for a long-term maintenance relationship or an in-house team to keep developing it. | Usually the longest route, with a high initial investment. Statutory work such as general ledger accounting, the Turkish e-ledger (e-Defter) and official reporting would have to be rebuilt and kept current with every regulatory change, which is why on this route too we usually recommend keeping the statutory books in an off-the-shelf accounting package. | A project fee and an ongoing maintenance agreement instead of per-user licences; keeping up with regulatory changes is planned into maintenance. |
| Replacing your ERP with another package | The problem is fundamental rather than confined to a few processes: a multi-company or multi-site structure, user growth the current package no longer handles, a version that is no longer supported, or a core that simply does not meet your needs. | Data migration, retraining and a period of parallel running lengthen the switch and raise the risk. Processes specific to you may not fit the new package either, and the same problem can return in the new system. Check the new product's capabilities against your own scenarios, in the vendor's demo and in writing. | New licence or subscription, implementation, customisation, data migration and transition effort; obligations under the old system's licence and maintenance may run in parallel for a while. |
On the off-the-shelf and replacement routes, licence terms and the format in which you can export your data depend on the vendor's contract; ask your vendor or implementation partner before you buy.
This split applies to the second route, where a layer is added alongside your existing ERP or accounting software. In a custom ERP for your whole operation, customer accounts, collections and cash flow can also be built into the custom system, while the statutory books and e-documents can stay in a package or with the integrator. The rule of thumb: statutory records and compliance stay in the ERP; live, shop-floor and business-specific operations move to the layer. Each piece of data has one master location; the other system reads it rather than keeping its own editable copy. The exact split is written up during discovery, based on what your ERP can connect to.
| Process | Where it lives | Why | What flows between the systems |
|---|---|---|---|
| Accounting, customer and supplier accounts, invoices and statutory books | Stays in the ERP | Statutory records and compliance are what off-the-shelf packages are built around; on the layer route, rebuilding them adds needless workload. Check your product's coverage with your vendor. | The layer reads account and item master data from the ERP; it does not post accounting entries itself. |
| Turkish e-invoices, e-dispatch notes and e-archive invoices (e-Fatura, e-İrsaliye, e-Arşiv) | Stays in the ERP, or with the GİB-approved private integrator it connects to | Document numbering and the process with GİB, the Turkish Revenue Administration, should run from a single point; as formats and obligations change, keeping updates in one place lowers the risk. | The shipment is prepared in the layer; the dispatch note is issued in the ERP or by the integrator, and the document number flows back to the layer. |
| Item master, bills of materials (or recipes, in process industries) and costing | Depends | The master record for items and bills of materials usually stays in the ERP. Detailed costing, such as scrap, labour or subcontracting, is done in the layer if the package falls short. | The layer reads items and bills of materials; calculated costs or actual consumption are passed to the ERP through a supported route. |
| Shop floor and production: work order tracking, operator entry, downtime and scrap | Usually moves to the layer | Data has to be entered at the machine, live and with a single tap; designing those screens for the shop floor is easier in the layer. | Work orders are pulled from the ERP or opened in the layer; actual output, scrap and material consumption are written back to the ERP. |
| Warehouse: bin locations, picking, stock counts, barcode goods in and out | Usually moves to the layer | Movements happen live, with handheld terminals and barcodes; bin layout and picking logic are specific to each business. | Movements are captured in the layer and quantity changes are posted to the ERP; the item master stays in the ERP. Bin-level stock is held in the layer and warehouse totals in the ERP; which system records goods receipt is agreed up front. |
| Quality: measurements, acceptance and rejection, samples, non-conformance records | Usually moves to the layer | Inspection points, measurement plans and approval flows vary by industry and by customer. | A rejection or quarantine decision is reflected in the ERP's stock status through a supported route. |
| Traceability: lot/batch and serial numbers; the chain from raw material to shipment | Usually moves to the layer | Building the chain requires shop-floor, warehouse and quality data to come together in one place. | Shipment and invoice details are read from the ERP; backward and forward tracing is done in the layer. Whether the master record for lot and serial numbers sits in the ERP or in the layer is decided during discovery; the other system reads it. |
If your ERP's production, warehouse, quality or lot/serial module covers the need, these processes can stay in the ERP; scope varies by product and version. Which records can be written from outside also varies by product, version and licence. Ask your ERP vendor or implementation partner about both.
Cost calculations usually drift not because of the software but because the data entering the ERP is incomplete or late. The table below shows the most common sources and how a layer that collects data from the shop floor closes them.
| Source of the gap | Why it happens | How the layer closes it |
|---|---|---|
| Scrap and waste | Actual scrap on the floor is not recorded, or is deducted at a fixed recipe rate. | Scrap and waste are recorded from the floor per work order, so the recipe rate and the actual figure sit side by side. |
| Subcontracting cost | Goods sent to and returned from subcontractors, scrap at the subcontractor and the subcontracting fee are not tied to the order. | Subcontract dispatches, returns and invoices are linked to the relevant work order. |
| Labour time | Labour is costed at standard times; actual time is unknown. | Actual time is measured from work-order start and finish records. |
| Energy and production overheads | Overheads are spread across products with a rough key. | Machine run time or meter data can be used as the allocation key; the allocation method is agreed with your accountant. |
| Out-of-date recipes | The product changes but the recipe in the ERP stays old. | Recipe revisions, and which revision each batch was made with, are recorded. |
| Raw material prices and exchange rates | Cost is calculated with an old purchase price or an out-of-date exchange rate. | The latest purchase price and the exchange-rate rule are fed into the cost calculation as inputs. |
The layer does not set the cost itself; it collects accurate data from the floor and feeds it into the cost calculation in the ERP. The costing method (standard or actual) and accounting entries stay with the ERP and your accountant.
An ERP project does not go live all at once; it starts with the most critical module. Each phase is handed over with the pieces below.
| Deliverable | What it is for |
|---|---|
| A live version of the priority module | You see value early, and later modules are scoped with what the first one taught us. |
| Data migration and reconciliation results | Record counts and totals migrated from the old system are compared with the source. |
| Accounting and e-document links with transfer logs | You can see which record moved when, in which direction, and which records failed. |
| User training | Each role is trained on its own screens, so knowledge does not sit with one person. |
| Source code and data | The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences. |
The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call. If the items below are ready, we can work out more quickly which route suits you; anything missing, we will fill in together during discovery.
We observe your production, inventory and costing processes on site, mapping the current flow and the real bottlenecks. At this stage we answer the question clearly: off-the-shelf package or custom build?
We design a data model fitted to your recipes, warehouses, accounts and cost structure, on an API-first, modular architecture. The scope of the Logo/SAP bridge and other integrations is fixed here.
We take the module that creates the most critical value (usually production/work orders or inventory) live first. With an early working piece you see the value, and we prioritise the rest accordingly.
We connect the accounting system, e-invoicing and, where needed, shop-floor devices, and migrate your legacy stock and account data after cleansing it. Every sprint ends with a visible deliverable that has gone through a review step before release.
We go live in stages without stopping production, and train the users. The system then keeps evolving under a maintenance relationship, defined in the contract, covering monitoring, security and further development.
If your processes are standard and fit the package, an off-the-shelf ERP is a fast and sensible start. But if your recipes, scrap, subcontracting or costing are your competitive edge and no package truly fits, custom development can be the more flexible route; total cost depends on scope, number of users and maintenance period. In the first call we compare both options with you; very often the right answer is an off-the-shelf package for accounting and a custom layer for production.
Timeline and cost depend mainly on the modules in scope, the number of users and sites, the depth of accounting and e-document integration, data migration and the state of your bills of materials. A single module can take a few weeks; a comprehensive ERP can take several months. Because we work iteratively rather than to a fixed scope, cost is finalised after discovery; we do not quote unrealistic figures — the price takes shape with the scope. By taking the most critical module (the MVP) live first, you see value early and manage the budget step by step.
Yes. The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences. Technical documentation and the database are handed over too; you can carry on with another team if you wish.
In most cases, yes. A two-way connection with systems such as Logo (a widely used Turkish ERP), SAP or Mikro is usually possible; accounting stays where it is while production and costing run in the custom ERP. The custom layer connects to your ERP through the routes its vendor supports (API, service layer or an approved import); it does not write directly into the ERP's database tables. The route depends on the version and licence and is agreed in writing during discovery. E-invoices go through your private integrator's API, or through direct GİB integration where you are authorised for it. In production, barcode/RFID is a method we often use. Eliminating duplicate data entry is a core goal.
Yes. We bring the system live in stages rather than all at once; one module or one department goes first, and the old method runs in parallel for a while. Data migration and user training follow that plan, so the risk of interrupting production is reduced.
There is. We offer monthly maintenance packages, with scope and response times defined in the contract, covering monitoring, security updates, bug fixes and new feature development. ERP is a living product; as your business processes change, the system evolves with you.
ERP (enterprise resource planning) is software that brings a business's production, stock, purchasing, costing, finance, sales and shipping processes together on a single data backbone. Because every department sees the same stock, the same cost and the same order status, information flows inside the system rather than between spreadsheets. We build ERP on a modular architecture that talks to your existing accounting system, and take the most critical module live first.
We listen to what you need and tell you whether custom development or an off-the-shelf product fits better. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
We develop a manufacturing execution system built for your factory — making the shop floor visible in real time, from work orders to OEE, scrap to shifts, running on a PLC/SCADA bridge and shop-floor terminals.
Details →We design the whole chain from sensor to cloud: device firmware, MQTT-based telemetry, edge processing and a remote monitoring panel. Your machines, production line and field equipment come together in a single data stream — and the source code we write is handed over to you.
Details →We collect a machine's vibration, temperature, current and cycle data, learn its normal operating signature, and catch deviations from that signature before failure occurs. An alert becomes a maintenance work order; the machine's history and the parts used accumulate in the same record.
Details →We build camera-based visual inspection on the production line: surface defects, colour and shade variation, missing parts, label verification and dimensional checks. The work does not begin as a software installation — it begins with feasibility and sample testing.
Details →We generate demand forecasts from order history, seasonality and stock data, and link that forecast to your production and purchasing plans. We sequence work under capacity constraints, calculate safety stock and measure how accurate the forecast actually was.
Details →We build a system that collects labour data from the shift plan to the time-and-attendance terminal, from overtime to piece-rate incentives, and prepares the file that goes to payroll matched against production records. Who has earned what is clearly visible, so disputes are easier to settle.
Details →