When connecting your e-commerce site to ERP and e-invoicing, the decision comes down to a simpler question than most companies assume: is your store one of the platforms supported by a ready-made connector, or is it a code-based/custom build? If the answer is the former, in most cases a ready-made connector (such as Entegra, Sopyo, or Sentos) is enough: you pay a monthly subscription plus a per-document credit (kontör), setup is fast, and the maintenance burden is not on you. If the answer is the latter — that is, you are not on a named, listed platform like WooCommerce, Shopify, or İkas — the "happy path" of ready-made connectors does not cover you, and commissioning a custom API bridge (or calling a connector's API from your own bridge) becomes the only sound route. The critical technical fact is this: in Türkiye, e-Invoice/e-Archive is a structured XML document mandated by the Revenue Administration (GİB) — there is no OCR over a PDF or scan; the document is generated programmatically and transmitted within seconds. In other words, "invoice integration" is not image recognition but the work of producing and parsing tagged XML. Below, we present this decision not as a slogan but through a measurable decision matrix and total cost of ownership (TCO) reasoning. As a Sakarya-based B2B / white-label software firm that makes this choice constantly for agency owners and enterprise buyers, we share the exact framework we use.
In this article, instead of a generic "integration is good" sermon, we get into the mechanics: the XML reality of e-invoicing, what actually needs to be synchronized (stock, price, orders, invoices, returns), the pros and cons of a ready-made connector, the pros and cons of a custom bridge, a decision matrix, and finally the "credits vs. development + maintenance" TCO reasoning. We covered the topic in a broader frame earlier in our pieces on custom software vs. off-the-shelf software and company-specific ERP/CRM; here we add a layer specific to the e-commerce + ERP + e-invoicing triangle.
The XML reality of e-invoicing: there is no OCR here
The most common wrong assumption is to think of e-invoice integration as "scanning an invoice and importing it into the system." In Türkiye, the situation is different. GİB has adopted a structured XML standard called UBL-TR for e-Invoice/e-Archive; documents are prepared according to this schema package (with UTF-8 encoding). API integration means that your order/sales/ERP software connects to GİB or to a private integrator's web service and creates, sends, and tracks the status of the invoice without human intervention — because the document is machine-structured XML end to end, there is no OCR step, neither when issuing nor when receiving an invoice.
The practical consequence is this: the heart of the integration is mapping fields such as line items, tax rates, counterparty (buyer) information, and document type to the correct XML fields. According to GİB's own official definition, an e-Invoice can be issued through three methods: the e-Invoice Portal, Integration (the taxpayer's own system connecting directly, 24/7), and Private Integration / Private Integrator. A private integrator serves, in GİB's official wording, to receive and send e-invoices on the taxpayer's behalf "through the information system of a private integrator with technical competence"; it must have passed GİB's tests and been approved (GİB — Private Integration). In practice, a private integrator takes on the GİB connection and infrastructure and usually exposes a REST API to you. This distinction is also the foundation of your "ready-made connector or custom bridge" decision; we handle the API side as part of our API integration service.
What actually needs to be synchronized?
An e-commerce ↔ ERP ↔ e-invoicing bridge is not a single "data transfer"; it is five flows with distinct life cycles. Whichever solution you choose, you have to model all five:
- Stock: Usually bidirectional. A quantity change in the ERP should reflect on the site, and a sale on the site should reflect in the ERP. Otherwise, you keep selling a product that is already out of stock.
- Price & product: The price/product definition flows from the ERP to the site in most setups; campaign prices require special attention here.
- Order: Flows from the site to the ERP. The critical point: in most connectors this flow is not a real-time push but runs on intermittent polling (details below).
- Invoice: Order → invoice conversion. Here the e-Invoice/e-Archive/e-SMM document is produced programmatically and formally registered with GİB.
- Return: The most frequently overlooked flow. It is not possible to "delete" an issued e-Invoice; a return/partial return is modeled with a separate accounting document (a return invoice).
These five flows have different latency and consistency requirements. For example, in order synchronization, many ERP integrations work on a batch/polling logic: according to the documentation of IdeaSoft and similar connectors, orders coming from the site are pushed into Mikro ERP through a secure web-service layer at roughly 15-minute intervals (not via direct database access), while stock/product/price are synchronized bidirectionally (IdeaSoft — Mikro integration). This ~15 minutes is a connector-application behavior, not a guarantee of the "Mikro" platform; moreover, "Mikro" spans different product lines (Jump/Fly/older versions) with varying integration surfaces. You need to account for this polling reality when planning your order→invoice latency.
Idempotency: the sneakiest engineering risk in the bridge
Because it works via sync polling and e-Invoice/e-Archive documents are registered once with GİB, a naive bridge can issue a duplicate invoice on a retry or a repeated order webhook. That means duplicating a legal document — problematic both for the customer and from a fiscal standpoint. A robust bridge requires an idempotency key per order, exactly-once invoice creation, and careful management of status flags such as e_invoice_sent/e_archive_sent. This is a direct engineering requirement derived from GİB's registered-document model and the observed polling behavior. We addressed the same webhook/idempotency rigor on the virtual POS side in our virtual POS integration guide; the same discipline applies to the invoicing flow.
Ready-made connector: pros and cons
Ready-made connectors (such as Entegra, Sopyo, Sentos, and İkas) build a bridge to ERP/pre-accounting targets (Logo, Netsis, Mikro, Paraşüt, and more) and to the e-invoicing system; but their support is built around a fixed list of mostly-SaaS e-commerce platforms. For example, Entegra bidirectionally connects ERP targets such as Logo, Netsis, Mikro, SAP, ETA, Zirve, DİA, Nebim, Paraşüt, Link, and Microsoft Dynamics, and e-commerce platforms such as IdeaSoft, Ticimax, OpenCart, T-Soft, Hipotenüs, WooCommerce, Shopify, PrestaShop, and Magento; it offers one-click order→invoice, bidirectional stock/price sync, and automatic counterparty creation (Entegra — e-commerce integration). Sopyo similarly lists platforms such as Shopify, WooCommerce, IdeaSoft, İkas, and Ticimax alongside Logo/Mikro/Paraşüt and e-invoicing targets.
| Pros | Cons |
|---|---|
| Fast setup; order→invoice, stock/price sync, and automatic counterparty creation with no coding. | Supports only named, listed platforms; a custom/code-based store falls outside the "happy path." |
| Maintenance burden sits with the provider: API version changes and GİB compliance are their problem. | Recurring cost: subscription + per-document credit; it grows as volume grows. |
| Ready-made compatibility with many ERP/e-invoicing targets; the testing burden is not on you. | Limited customization; narrow flexibility for bespoke business rules/field mappings. |
| Low entry cost for small/medium volume and standard flows. | A campaign/Black Friday peak directly raises credit consumption and volume/limit risk. |
Here is the real gap: these connectors target the named, mostly-SaaS platforms and do not list support for fully custom/code-based stores. Sentos's integration page lists only specific platforms (İkas, Ticimax, Shopify, IdeaSoft, Hipotenüs, T-Soft, OpenCart, WooCommerce, Ethica) and does not mention custom/proprietary software (Sentos — B2C integration). Similarly, İkas's pre-accounting/ERP integrations (Logo İşbaşı, Mikro, Nebim, Uyumsoft, Akınsoft Wolvox, DİA, Microsoft Dynamics, Netsis, Zirve, Link, the free BirFatura/Bizim Hesap, etc.) exist — but they exist because İkas itself is a hosted SaaS platform; the integration surface is between the İkas platform and the ERP, so a code-based custom store cannot reuse it without migrating onto İkas (İkas — pre-accounting integrations).
Custom API bridge: pros and cons
A custom bridge is a layer written to your business rules, in which your site (or an intermediary service) calls the APIs of the ERP and a private integrator/accounting platform directly. The APIs of modern targets are well-suited to this. For example, Paraşüt offers an official REST API (v4); it uses OAuth2 for authentication (host api.parasut.com, basePath /v4). Authorization goes through the /oauth/authorize and /oauth/token endpoints; the access_token is of Bearer type and expires within 2 hours, renewed via a refresh_token. The specification documents three OAuth2 grant types: authorization_code, password, and refresh_token; the default redirect URI is urn:ietf:wg:oauth:2.0:oob (Paraşüt — official API documentation (swagger)).
More importantly, the Paraşüt API exposes e-Invoice, e-Archive, and e-SMM resources directly: /{company_id}/e_invoices, /{company_id}/e_archives, .../pdf endpoints for the PDF, and a documented invoice status enum (printed, not_printed, invoices_not_sent, e_invoice_sent, e_archive_sent, e_smm_sent). So for programmatic invoice creation and PDF retrieval, no separate OCR/document step is needed. On the ERP side, Logo Netsis offers a REST API named "NetOpenX Rest" in its official documentation; this API standardizes NetOpenX functions to push and pull data to and from the ERP for web/mobile integration without breaking the business logic (Logo — Netsis customization tools). The existence and functional scope of this API are verified; we do not claim its exact authentication mechanism (token or session) here — positioning it as a REST API with its own auth is sufficient.
| Pros | Cons |
|---|---|
| Works with a custom/code-based store; you are not bound to a ready-made list. | Upfront development cost + ongoing maintenance (API version changes, retries, sync drift). |
| Full fit to business rules: field mapping, idempotency, and the return flow are under your control. | Requires correct engineering; OAuth token refresh and error/queue handling must not be neglected. |
| You design the architecture beyond credits; you are not at the mercy of provider lock-in. | You must track GİB/regulatory and integrator API changes on your own schedule. |
| A predictable architecture independent of volume; versioning and observability are yours. | Note: e-invoice documents still go through a private integrator/GİB; the credit line item usually does not disappear. |
Note: a custom bridge does not mean "getting rid of credits entirely"; e-invoice documents still go to GİB/the private integrator, where a per-document credit is consumed. What a custom bridge gains you is that the orchestration and business-logic layer belongs to you — whatever platform you are on. We run custom bridge work together within the scope of custom web software and CRM/ERP solutions.
Decision matrix: when is ready-made enough, when is custom a must?
To make the decision intuitive, here are single-line rules:
| Situation | Lean toward | Rationale |
|---|---|---|
| Store on a SaaS platform the connector lists (WooCommerce, Shopify, İkas, Ticimax…) | Ready-made connector | The happy path covers it; setup is fast, maintenance sits with the provider. |
| Fully custom / code-based store, an unlisted build | Custom bridge | Ready-made connectors do not cover this store; you call the ERP/integrator API yourself. |
| Standard flow, low customization, medium volume | Ready-made connector | If there are no custom rules, there is no need for an upfront development cost. |
| Bespoke business rules (custom return logic, B2B pricing, multi-store/multi-counterparty) | Custom bridge | Field mapping, idempotency, and the return-invoice flow demand full control. |
| Very high/volatile volume, strict SLA | Usually custom (or hybrid) | Credit and limit management plus a queue/retry architecture demand predictability. |
The decision is not "which one is better" but "which box does your store fall into." If you are on a listed SaaS platform, a ready-made connector is usually enough; if you have a custom/code-based store or bespoke business rules, a custom bridge is not a preference but a necessity.
Do not underestimate the return flow
Whichever route you choose, you have to model returns separately. Because an issued e-Invoice/e-Archive is registered with GİB, it simply cannot be "deleted": within a short cancellation window, an e-Archive can be canceled and reported to GİB, and once that window closes, a correction/return is made with a return (credit) document (Paraşüt — e-Archive cancellation vs. return). Handling full and partial returns separately is essential to keep stock, counterparty balances, and tax records consistent. We do not state the cancellation window's number of days as a hard rule here — sources differ; if you need a precise duration, rely on the current GİB e-Archive communiqué/guide.
TCO reasoning: credits, or development + maintenance?
The decision is really a choice of cost form: a ready-made connector is a recurring expense (subscription + per-document credit), while a custom bridge is an upfront development + ongoing maintenance expense. The numbers are volatile as of 2026 and vary by provider/volume; so read the following not as exact prices but as approximate market ranges.
- Credit (a per-document digital credit): Generally ~1 credit is spent per outgoing document (some providers also charge for incoming ones). According to 2026 market-comparison data, the credit unit price at mainstream providers averages roughly 0.75–1.50 TL/document; at ERP-integrated enterprise integrators it can be higher per document (reported at ~5–10 TL) (Faturaport — 2026 credit prices (not an official list)). These are not official vendor prices but a dated market comparison.
- Subscription: Faturaport's 2026 cost guide gives subscription bands on an annual basis (e.g., e-invoice only ~300–1,500 TL/year; SMB ~1,500–6,000 TL/year; enterprise ~6,000–50,000+ TL/year, quote-based), and there are also recurring fiscal seal/e-signature certificate costs (Faturaport — 2026 e-invoice cost guide (not an official list)). These bands, too, are approximate and provider-dependent.
- Volume sensitivity: Because credits and subscriptions grow with volume, a campaign/Black Friday peak directly raises credit consumption and can push you toward volume/limit thresholds.
A custom bridge trades this recurring model for upfront development + ongoing maintenance: line items such as API version changes, retry/queue logic, and sync drift generate cost over time. Your focus should not be memorizing the unit price but understanding the mechanism: if your document volume is large and predictable, the recurring credit line item may eventually exceed the upfront development + maintenance cost; if your volume is low or your platform is already supported, a ready-made connector is far more economical. Evaluating the general frame alongside the logic in our custom vs. off-the-shelf software piece clarifies this trade-off.
Partnerfy's B2B / white-label approach
As a Sakarya-based B2B / white-label software engineering firm, we treat this decision not as a "promise" but as a process: first we diagnose which box your store falls into (a listed SaaS platform, a custom/code-based build, or one with bespoke business rules), then we map the five flows (stock/price/order/invoice/return), and finally we either position a ready-made connector correctly or write a custom API bridge with idempotency and the return flow set up properly. For agencies, we deliver this bridge under your brand in a white-label model; for enterprise buyers, we unite e-commerce systems and CRM/ERP solutions on a single observable line.
To be honest: no bridge can guarantee zeroing out credits or that GİB regulations will never change — these are external variables. Our promise is not a guarantee but a foundation: an architecture that issues invoices exactly once, models returns with a separate document, does not neglect token refresh and retries, and handles volume peaks. We also cover work with a code base, custom business rules, or an unexpected ERP line on the custom web software side.
Sonuç
In an e-commerce ↔ ERP ↔ e-invoicing bridge, the right question is not "which one is better" but "which box does my store fall into." If you are on a listed SaaS platform and your flows are standard, a ready-made connector is usually enough — provided you accept the recurring subscription + credit fee. If you have a custom/code-based store or bespoke business rules, a custom API bridge is not a luxury but a necessity. In either case, e-invoicing is not an OCR job but a UBL-TR XML job; modeling idempotency and the return flow correctly is non-negotiable. If you are unsure where to start, get in touch with us; let us classify your store and produce a tailored "ready-made connector or custom bridge" decision and a cost-form comparison for you.
Kaynaklar
- GİB — Private Integration (the three e-Invoice methods and the official definition)
- GİB — e-Document (e-Invoice/e-Archive) portal and the e-Invoice package (UBL-TR schemas)
- Paraşüt — Official API documentation (OAuth2, v4, e_invoices/e_archives, PDF endpoints, status enum)
- Logo — Netsis customization tools / NetOpenX Rest API
- Entegra — e-commerce integration (ERP targets + platform list)
- Sentos — B2C e-commerce integration (fixed platform list)
- İkas — pre-accounting/ERP integrations
- IdeaSoft — Mikro integration (~15 min polling, web-service layer)
- Faturaport — 2026 credit prices (market comparison, not an official list)
- Faturaport — 2026 e-invoice cost guide (annual subscription bands, not an official list)
- Paraşüt — e-Archive cancellation vs. return invoice (conceptual)