Automated Multi-Platform EDI Integration for B2B Retail: A Romanian Case Study on System Architecture, Implementation, and e-Factura Convergence

Abstract

The mandatory introduction of Romania’s national e-invoicing system, ANAF e-Factura, in January 2024 has reshaped B2B document exchange in the retail sector, but suppliers still operate in parallel with two proprietary electronic data interchange (EDI) platforms, EDINET and DocProcess, which increases integration complexity. This paper presents the architecture, implementation, and evaluation of a custom Laravel-based B2B platform developed to automate commercial workflows across these three channels. The system supports XML purchase order ingestion and normalization, product identifier resolution, unified order persistence, platform-specific invoice XML generation, and ANAF SPV submission via SmartBill and Oblio REST APIs. A comparative analysis of real production XML documents showed full field-level overlap across 21 invoice data dimensions, with the main differences between systems related to entity identification schemes rather than business information content. During 2025, the platform processed 1247 EDI purchase orders and achieved an 87.30% fully automated processing rate, reaching 94.60% by year-end through progressive product catalog enrichment. The results indicate that ANAF e-Factura is technically capable of covering the core invoice exchange function currently duplicated by proprietary EDI platforms, while their coexistence continues to impose additional integration effort and slows SME digital transformation, particularly for small and medium-sized suppliers.

1. Introduction

The digital transformation of supply chains has accelerated markedly in recent years as firms have pursued greater operational efficiency, traceability, and regulatory compliance. In retail and fast-moving consumer goods (FMCG) ecosystems, Electronic Data Interchange (EDI) has become a key infrastructure for inter-organizational coordination, enabling structured machine-to-machine exchange of purchase orders, invoices, and related business documents. At the same time, XML-based business document standards such as Universal Business Language (UBL) and the European e-invoicing semantic model EN 16931 have provided a formal basis for interoperable document exchange across heterogeneous enterprise systems [1,2]. In practice, however, large-scale B2B document exchange often remains mediated by proprietary intermediary platforms that preserve retailer-specific schemas, identifiers, and validation rules, thereby limiting interoperability despite the availability of open standards [3,4,5].

This tension is especially visible in the Romanian retail sector. Large retailers such as Carrefour, Kaufland, Auchan, Metro Cash & Carry, Profi, and REWE require suppliers to exchange commercial documents electronically, yet the market is split between two dominant proprietary EDI platforms: EDINET and DocProcess. Although these platforms support the same underlying business process, they rely on distinct XML structures, different entity-identification conventions, and incompatible invoice-output requirements. As a result, suppliers operating across multiple retail chains must maintain parallel integration pipelines, each with dedicated parsing, normalization, validation, and document-generation logic. This burden falls disproportionately on small and medium-sized suppliers, for whom integration cost, maintenance effort, and exception handling represent significant barriers to digital participation in retail supply chains [4,5,6,7,8].

The Romanian context became more complex with the mandatory rollout of the national e-invoicing system RO e-Factura for domestic B2B transactions beginning in January 2024. Under this framework, invoices must be transmitted through the ANAF Virtual Private Space (SPV) in a structured XML format based on EN 16931, UBL 2.1, and the Romanian RO_CIUS national extension [2,9,10,11,12]. Romania’s B2B mandate was enabled through a derogation from the VAT Directive granted by the Council of the European Union, and it forms part of a broader European transition toward digital reporting and e-invoicing convergence under the VAT in the Digital Age (ViDA) agenda [10,13,14]. The practical consequence is a structural duplication problem: for a single commercial transaction, suppliers may now need to produce invoice data for the state-operated e-Factura channel in parallel with platform-specific invoice outputs required by proprietary retail EDI intermediaries.

Although the literature has extensively examined EDI adoption, SME digitalization barriers, and the benefits of electronic invoicing, comparatively little attention has been paid to environments in which mandatory public e-invoicing infrastructures coexist with multiple proprietary B2B document platforms in the same national retail ecosystem [6,7,8,15,16,17,18]. This creates a relevant research gap at the intersection of interoperability, regulatory digitalization, and enterprise integration architecture: when a legally mandated public invoicing system already captures and validates the complete fiscal document, to what extent do parallel proprietary invoice-routing layers remain technically necessary? Recent studies on supply-chain data spaces, interoperable knowledge-graph models, and SME-oriented digital transformation have further shown that information integration quality and standardized data exchange remain decisive for automation maturity and cross-organizational coordination in contemporary supply networks [19,20].

To address this question, the architecture, implementation, and evaluation of a custom Laravel-based B2B platform developed for a Romanian supplier operating across multiple large retail partners are presented. The platform automates the complete workflow from XML purchase-order ingestion and source detection to product identifier resolution, unified order persistence, platform-specific invoice XML generation, and ANAF SPV submission via SmartBill and Oblio REST APIs. Building on real production XML documents and operational data, four contributions are made. First, a structured comparative analysis of EDINET, DocProcess, and ANAF e-Factura invoice representations is provided, and the main points of overlap, divergence, and redundancy are identified. Second, a production-grade multi-source integration architecture for heterogeneous XML processing in a fragmented B2B retail environment is described. Third, empirical evidence from real 2025 operational data regarding automation rates, catalog enrichment effects, and document-generation overhead is reported. Fourth, these findings are used to evaluate the convergence hypothesis that the mandatory public e-invoicing infrastructure may be technically capable of covering the core invoice-exchange function currently duplicated by proprietary EDI platforms.

Beyond its immediate national setting, the Romanian case is relevant to other EU member states moving toward mandatory e-invoicing and digital reporting. As ViDA-related reforms advance, similar tensions may emerge between legacy proprietary B2B infrastructures and public, standardized reporting channels. The present study therefore contributes not only a national case study but also an implementation-level perspective on interoperability, redundancy, and convergence in digitally regulated supply-chain information systems [13,14,17,18].

The remainder of the paper is organized as follows. Section 2 presents the study design, operational context, data sources, system architecture, and methodological framework. Section 3 reports the comparative and operational results. Section 4 discusses the implications of the findings and the convergence hypothesis. Section 5 concludes the paper and outlines future work.

2. Materials and Methods

2.1. Study Design and Operational Context

An implementation-grounded case-study design was used to investigate interoperability, automation, and redundancy in a fragmented B2B document-exchange environment. The research focuses on a Romanian supplier operating across multiple large retail partners that require electronic document exchange through two proprietary EDI intermediary platforms, EDINET and DocProcess, while also complying with the mandatory national RO e-Factura framework for legally valid B2B invoicing [1,2,11,12,13,14,15]. The methodological objective was twofold: first, to examine how structurally different XML-based document ecosystems can be normalized into a common internal processing model; and second, to assess whether the coexistence of proprietary retailer-facing invoice channels and the public e-invoicing channel reflects a genuine information need or mainly a format-level and identifier-level duplication problem [6,7,8,18].

The study is based on a live production deployment rather than on a laboratory prototype. This choice is important because the practical challenges addressed in the paper do not arise only from formal schema definitions, but also from the irregularities of real document exchange, including incomplete product identifiers, free-text address variations, retailer-specific output constraints, and repeated correction or overwrite scenarios. The Romanian setting is particularly relevant because mandatory domestic B2B e-invoicing now coexists with retailer-imposed proprietary XML ecosystems rather than replacing them, thereby creating a three-channel operational environment for the same underlying commercial transaction [11,12,13,14,15]. In this context, the platform developed in the study serves both as an operational business system and as a research artifact through which heterogeneous document flows can be captured, normalized, compared, and evaluated.

2.2. Materials and Data Sources

The empirical material analyzed in this study consists exclusively of real production data collected between 1 January 2025 and 31 December 2025 from the deployed supplier platform. The dataset includes incoming XML purchase orders received through EDINET and DocProcess, outgoing platform-specific invoice XML files generated for retailer submission, invoice submission records associated with RO e-Factura transmission through SmartBill and Oblio, and internal operational traces stored in the platform database. These traces include import logs, overwrite events, validation failures, invoice export histories, and API submission outcomes. No synthetic, simulated, or manually fabricated XML payloads were used in the evaluation dataset. The use of production data ensures that the analysis reflects real integration conditions rather than idealized schema examples [11,12,13,14,15].

The document systems under analysis are EDINET, DocProcess, and RO e-Factura. EDINET is used in the studied deployment by Auchan, Metro Cash & Carry, and REWE Romania, whereas DocProcess is used by Carrefour, Kaufland, and Profi. RO e-Factura is the mandatory public invoicing infrastructure through which legally valid B2B invoices are transmitted to the ANAF Virtual Private Space (SPV) [11,12,13,14,15]. Each of these systems represents the same commercial event using different XML structures and different entity-identification logic. The platform therefore operates over three concurrent document representations: retailer-facing order input, retailer-facing invoice output, and fiscally authoritative invoice transmission.

The software materials used in the study include the Laravel 10 framework, PHP 8.x, MySQL, PHP’s native DOMDocument API for XML generation, Laravel Eloquent ORM for persistence, Laravel’s HTTP client for external API communication, and locally maintained lookup tables for product and geographic resolution. External invoicing connectivity is provided through SmartBill and Oblio REST APIs, which accept normalized invoice data and perform RO_CIUS-compatible invoice generation and ANAF SPV submission on behalf of the supplier [11,12,13,14,15].

2.3. Systems Under Study

The system examined in this paper is a custom Laravel-based B2B integration platform designed to automate the complete commercial workflow from order ingestion to invoice generation and submission. Architecturally, the platform is organized around three input channels. Channel 1 handles EDINET orders; Channel 2 handles DocProcess orders; and Channel 3 handles standard website orders originating directly in the supplier’s own storefront. Channels 1 and 2 require source-specific XML ingestion, parsing, normalization, and invoice re-generation in retailer-specific formats. Channel 3 bypasses the EDI ingestion stage entirely and proceeds directly to invoice submission through SmartBill or Oblio. This design creates a useful contrast between fragmented EDI-mediated workflows and a simplified direct e-invoicing workflow [11,12,13,14,15].

The platform uses a hub-and-spoke logic. External partner systems remain format-specific at the edges, while the application core maintains a common internal order representation. Incoming XML orders are transformed into this shared model, persisted in relational form, and then expanded again into destination-specific invoice outputs. This architectural approach isolates business logic from source-level heterogeneity and allows downstream modules such as stock handling, status tracking, reporting, and invoice generation to operate independently of whether an order originated from EDINET, DocProcess, or the web storefront [17,18,21].

2.4. Source Detection and XML Parsing Procedure

Incoming XML documents are first processed by a source-detection layer. Because the platform receives files from multiple retailers and two proprietary EDI families, source recognition cannot rely on a single universal namespace or schema identifier. Instead, the system uses a heuristic content-based classification process supplemented by filename-based fallback rules. Detection examines document-body patterns such as retailer names, characteristic XML structures, fiscal identifiers, and GLN-related routing elements. The output of this stage is a normalized internal source label that determines parser selection, billing-profile assignment, and later invoice-generation rules [3,4].

After source detection, the document is routed to one of two parsing branches. The EDINET parser handles orders associated with Auchan, Metro, and REWE, while the DocProcess parser handles Carrefour, Kaufland, and Profi. The two parsing branches differ because the two ecosystems use distinct root structures, element naming conventions, and nesting strategies. EDINET relies on a proprietary envelope model with sections such as <OrderHeader>, <OrderParty>, and <OrderDetail>, while DocProcess uses a structure closer to UBL-like naming conventions with elements such as <BuyerCustomerParty>, <SellerSupplierParty>, and <OrderLine> [1,2].

Both parsers convert the XML documents into associative structures and then map extracted values into a common intermediate representation. Special handling is applied to normalize single-line and multi-line item collections so that downstream processing always receives iterable product-line arrays. This normalization step is essential for maintaining stable downstream behavior across structurally different source schemas. The output of the parser layer is therefore not a format-specific data object, but a unified order representation suitable for persistence, validation, and invoicing.

2.5. Unified Data Model and Persistence Logic

Following parsing, orders are stored in a common relational model composed of a main order table and a related order–line table. In the implementation used in this study, EDI orders are persisted in shoporders, while line-level information is stored in shoporderproducts. This common model decouples the downstream commercial workflow from the originating XML format. As a result, stock handling, order state tracking, invoice triggers, and reporting routines operate on a stable internal schema regardless of whether the source document originated in EDINET or DocProcess [18,19,20].

The platform also stores the raw imported document content as a JSON payload associated with the persisted order. This preserves traceability, supports debugging and reprocessing, and allows later comparison between source content and generated outputs. The persistence layer additionally implements idempotent overwrite handling. If an incoming order matches an existing combination of external order number and delivery GLN, the prior record is reset and overwritten rather than duplicated. This behavior is necessary because repeated transmissions and corrected versions of existing documents occur in practice. Before overwrite, billing fields, delivery fields, integration statuses, and product lines are cleared, and a structured audit note is recorded [3,4].

2.6. Product Identifier Resolution

A critical methodological component of the platform is product identifier resolution. In the studied retail environment, product lines may be identified using GTIN/EAN, <BuyerItemID>, <SellerItemID>, or numeric identifiers embedded in textual descriptions. The platform therefore implements a progressive multi-stage resolution strategy. First, it attempts direct matching using GTIN/EAN against the internal product catalog. If this fails, it inspects additional identifiers available in the order payload. If structured identifiers remain incomplete, the system performs description-level pattern extraction to identify long numeric sequences that may correspond to EAN values. When a valid identifier is recovered, it is written back into the internal catalog, thereby enriching the local master data for future imports [3,4].

This enrichment strategy is important because it transforms one-time exception handling into cumulative automation improvement. The manuscript later shows that the automatic processing rate increased during the evaluation period as a consequence of progressive catalog completion. At the processing stage, however, the system adopts a fail-fast policy: if one or more product lines cannot be resolved with sufficient confidence, the order import is blocked and a structured error report is returned to the operator. This prevents partial persistence and reduces the risk of downstream inconsistencies in stock allocation, invoice generation, and dispatch preparation. The resolution logic therefore acts as both a data-quality filter and an automation-learning mechanism.

2.7. Billing Profiles and Geographic Normalization

The platform applies retailer-specific billing profiles during order processing. These profiles contain locally maintained authoritative information for each supported retailer, including legal name, fiscal identifier, registered address, bank account, and IBAN. During invoice preparation, these profiles override or complete the corresponding values obtained from incoming EDI documents. This design reflects an important structural distinction in the ecosystem: proprietary retailer-facing EDI documents are primarily optimized for routing and operational partner identification, often using GLN-based logic, whereas Romanian fiscal invoicing requires legally authoritative entity identification based on CIF/CUI and RO_CIUS-compatible billing data [3,4,11,12,13,14,15].

The system also performs geographic normalization of free-text city names provided in incoming documents. A dedicated nomenclature table of Romanian localities is used together with a staged resolution procedure that includes case-insensitive exact matching, parsing of compound <Localitate>, <Județ> strings, and special handling for Bucharest-related variants. If no reliable match is found, the city field is logged as a warning and the order can proceed for later manual correction. This component exists because retailer-originated address fields are not always aligned with the structured geographic validation requirements associated with legally compliant fiscal invoicing [11,12,13,14,15].

2.8. Invoice Generation and External Submission Procedure

Once an order has been validated, processed, and prepared for dispatch, the platform generates invoice outputs according to source channel. For EDINET-originated orders, the system generates invoice XML conforming to the proprietary EDINET format. For DocProcess-originated orders, it generates a DXInvoice structure compatible with the retailer platform’s expected schema. In both cases, the same commercial event must also be submitted through the national e-invoicing path using SmartBill or Oblio, which generate the RO_CIUS-compliant invoice and transmit it to the ANAF SPV [11,12,13,14,15].

This means that an EDI-originated retail transaction may lead to two distinct invoice-facing XML outputs for the same underlying invoice: one proprietary XML artifact required by the retailer platform and one legally authoritative invoice submission through RO e-Factura. Website orders handled through Channel 3 require only the second path. Architecturally, this output asymmetry is central to the study because it makes redundancy observable and measurable. It is also methodologically important because it creates the basis for the later comparison between direct public e-invoicing and EDI-mediated dual-output workflows.

The external submission path is mediated through SmartBill and Oblio APIs rather than direct low-level SPV integration. These services accept normalized invoice data from the supplier platform, perform RO_CIUS XML generation internally, submit the invoice to the ANAF SPV, and return a validation token or error information. Submission status and related metadata are stored by the platform, creating a traceable record of invoice transmission outcomes [11,12,13,14,15].

2.9. Technology Stack and Execution Environment

The platform was implemented in PHP 8.x using Laravel 10, with MySQL used as the persistent storage layer through Eloquent ORM. XML generation for retailer-facing outputs was implemented using the native DOMDocument API in order to retain exact programmatic control over namespaces, element ordering, and schema-specific structural requirements. External API communication with SmartBill and Oblio was performed through Laravel’s HTTP client over HTTPS. The platform was deployed on a Linux server and operated in a synchronous, operator-triggered workflow during the evaluation period. This implementation profile is appropriate for a study centered on deterministic XML transformation, traceable persistence, and auditable workflow execution rather than on high-throughput distributed processing [18,20].

2.10. Comparative Method and Evaluation Scope

The analytical method combines architecture-oriented system inspection with structured XML comparison. For the comparative component, the three document systems active in the ecosystem—EDINET, DocProcess, and RO e-Factura—were examined directly on real production XML documents. The comparison focused on invoice-related representations and considered document root structure, party identification, delivery references, product-line representation, pricing fields, VAT-related fields, totals, and supporting references. The aim of this analysis was to determine whether the three ecosystems represent substantially different business information or whether the main divergence lies in structure and identification schemes [18,19,20].

The evaluation scope of the study is deliberately limited. It focuses on workflow automation, XML interoperability, and invoice-output redundancy in a live supplier deployment. The order-ingestion leg is described architecturally and assessed operationally through import success behavior, but it is not independently benchmarked for full semantic correctness at the line-content level against an external ground-truth dataset. Likewise, the empirical base derives from a single supplier operating in a specific product category, which supports strong implementation realism but limits broad statistical generalization across all supplier categories. These limits do not undermine the architectural contribution of the study, but they define it appropriately as an implementation-grounded case study rather than a market-wide statistical survey.

2.11. Research Aims

Based on the theoretical background and the methodological design presented above, three research aims were defined: (i) to compare the invoice-information content of EDINET, DocProcess, and RO e-Factura; (ii) to evaluate the operational performance of a unified Laravel-based integration platform in a live supplier deployment; and (iii) to assess whether the coexistence of proprietary retailer-facing invoice channels and the mandatory public e-invoicing channel introduces technically redundant processing steps.

2.12. Availability of Data, Code, and Operational Restrictions

The study relies on production commercial data containing retailer-specific operational information and supplier-side business records. For this reason, the raw XML documents, retailer billing profiles, and full application source code cannot be made publicly available in unrestricted form. However, the workflow logic, architectural design, processing stages, and comparative structure of the document systems are described in sufficient detail to support replication of the methodological approach. Additional redacted examples, field-mapping tables, pseudocode fragments, or implementation excerpts may be made available by the corresponding author upon reasonable request, subject to confidentiality constraints. This restriction is also reflected in the final Data Availability Statement, in line with the journal’s requirement to disclose limitations on access to materials and data.

3. Results

3.1. Comparative Results Across the Three Document Systems

The comparative analysis showed that the three document systems active in the studied ecosystem—EDINET, DocProcess, and ANAF e-Factura—encode substantially the same invoice-level commercial information despite marked differences in schema design, institutional role, and identification logic. The detailed field-level mapping presented in

Table 1. Field-level overlap between EDI invoice formats and ANAF e-Factura.

Information Field	EDINET Invoice	DocProcess Invoice	ANAF e-Factura
Invoice number	<InvoiceNumber>	<ID>	<ID>
Issue date	<Date>	<IssueDate>	<IssueDate>
Due date	<InvoiceDueDate>	<PaymentMeans> <PaymentDueDate>	<PaymentMeans> <PaymentDueDate>
Supplier CIF	<SellerParty> <TaxID>	<AccountingSupplierParty> <PartyIdentification>	<AccountingSupplierParty> (mandatory)
Supplier name	<SellerParty> <Name>	<AccountingSupplierParty> <PartyName>	<AccountingSupplierParty> <PartyName>
Supplier address	<SellerParty> <Street/City>	<PostalAddress>	<PostalAddress>
Supplier IBAN	<SellerParty> <BankAccount>	<PayeeFinancialAccount> <ID>	<PayeeFinancialAccount> <ID>
Buyer CIF	<BuyerParty> <TaxID>	<AccountingCustomerParty> <PartyIdentification>	<AccountingCustomerParty> (mandatory)
Buyer name	<BuyerParty> <Name>	<AccountingCustomerParty> <PartyName>	<AccountingCustomerParty> <PartyName>
Delivery GLN	<ShipToParty> <ILN>	<Delivery> <DeliveryLocation> <ID>	<Delivery> <DeliveryLocation> <ID>
Currency	<InvoiceCurrencyCoded>	<DocumentCurrencyCode>	<DocumentCurrencyCode>
Order reference	<OrderParty> <BuyerOrderNumber>	<OrderReference> <ID>	<OrderReference> <ID>
Line quantity	<QuantityValue>	<InvoicedQuantity>	<InvoicedQuantity>
Line net amount	<MonetaryNetValue>	<LineExtensionAmount>	<LineExtensionAmount>
Line tax amount	<TaxAmount>	<TaxTotal> <TaxAmount>	<TaxTotal> <TaxAmount>
Line gross amount	<MonetaryGrossValue>	<TaxInclusiveAmount>	derived
Unit price	<UnitPriceValue>	<Price> <PriceAmount>	<Price> <PriceAmount>
EAN/GTIN	<EAN>	<StandardItemIdentification> <ID>	<StandardItemIdentification> <ID>
Tax rate	<TaxPercent>	<Percent>	<Percent>
Total net	<NetValue>	<TaxExclusiveAmount>	<TaxExclusiveAmount>
Total gross	<GrossValue>	<TaxInclusiveAmount>	<TaxInclusiveAmount>

shows that all 21 invoice information fields considered in the analysis are present in ANAF e-Factura and in DocProcess invoice documents, while EDINET invoices cover 20 of the 21 fields, with the only minor deviation concerning the structure of the order-reference field rather than the absence of meaningful commercial content. The overlap includes invoice number, issue date, due date, supplier and buyer identity, delivery reference, quantities, prices, tax values, and document totals. The principal differences are therefore structural rather than semantic.

This conclusion is reinforced by the broader system-level comparison summarized in

Table 2. Summary comparison of EDINET, DocProcess, and ANAF e-Factura.

Dimension	EDINET	DocProcess	ANAF e-Factura (RO_CIUS)
Standard basis	Proprietary XML	UBL 2.1-inspired (proprietary extensions)	UBL 2.1/EN 16931/RO_CIUS
Primary entity identifier	GLN/ILN	GLN/EndpointID	CUI/CIF (fiscal code)
Platform-specific supplier ID	<SellerID> (numeric)	<CustomerAssignedAccountID>	None required
Order document schema	<Document Type = “Orders”>	<Order> (UBL-like)	N/A (no order format)
Invoice document schema	<Invoice Version = “1.0.1”>	<DXInvoice>	<Invoice> (UBL 2.1)
Tax data in orders	Absent	Partial (totals only)	N/A
Address format	Free-text, flat	Semi-structured	Strictly validated (ISO codes)
Legal status of invoice	Platform acknowledgement	Platform acknowledgement	Legal proof (validation token)
Mandatory since	Retailer-imposed (varies)	Retailer-imposed (varies)	January 2024 (Law 296/2023)
Operated by	Private VAN operator	Private VAN operator	ANAF (Romanian state)
Cost to supplier	Platform subscription fee	Platform subscription fee	Free (SPV access)

Note: N/A = not applicable.

. EDINET is based on proprietary XML and uses GLN/ILN-centered partner identification; DocProcess uses a UBL 2.1-inspired structure with proprietary extensions and GLN/EndpointID logic; and ANAF e-Factura is based on UBL 2.1, EN 16931, and RO_CIUS, with fiscal identity centered on CIF/CUI. In addition, the broader comparison in Table 2 highlights a decisive asymmetry: ANAF e-Factura is the only document channel whose output is legally authoritative, publicly operated, mandatory for domestic B2B invoicing, and free of access charges, whereas EDINET and DocProcess are retailer-facing proprietary platforms whose invoice outputs function only as commercial acknowledgements.

Taken together, Table 1 and Table 2 show that the mandatory public e-invoicing channel already contains the invoice information required by the proprietary retailer-facing invoice channels. From an empirical perspective, this is the foundation of the redundancy problem documented later in the section: the supplier platform must generate alternative XML renderings of invoice data that is already validated and stored in the ANAF SPV.

3.2. Order Processing Volume and Channel Distribution

During the full 2025 evaluation period, the platform processed 1247 EDI purchase orders across six retail partners, corresponding to 14,836 individual order lines. The distribution by retailer and platform is reported in

Table 3. EDI order volume by retailer and platform—full year 2025.

Retailer	Platform	Orders	Order Lines	Avg. Lines/Order
Carrefour	DocProcess	387	5241	13.50
Kaufland	DocProcess	198	2847	14.40
Profi	DocProcess	143	1632	11.40
DocProcess subtotal		728	9720	13.40
Metro	EDINET	241	2893	12.00
Auchan	EDINET	187	1748	9.30
REWE	EDINET	91	475	5.20
EDINET subtotal		519	5113	9.90

. DocProcess accounted for 728 orders and 9720 order lines, with an average of 13.40 lines per order, whereas EDINET accounted for 519 orders and 5113 order lines, with an average of 9.90 lines per order. At retailer level, Carrefour generated the largest volume, followed by Metro, Kaufland, Auchan, Profi, and REWE. These results show that the platform was evaluated over a heterogeneous and operationally significant transaction mix rather than over a narrow or artificial test set.

In addition to EDI-mediated transactions, the platform processed 3891 web storefront orders during the same period through Channel 3. These orders bypassed the EDI ingestion stage and were submitted directly to the SmartBill/Oblio invoicing API, serving as an internal baseline for processing-complexity comparison. In architectural terms, this distinction is consistent with the three-channel design already illustrated in Figure 1, where retailer-mediated flows require both external XML handling and dual invoice output, while web orders follow only the public invoicing path.

The monthly dynamics of these channels are shown in Figure 2, which indicates clear seasonality, with visible peaks in August and September corresponding to the back-to-school period. This behavior is consistent with the supplier’s stationery and art supplies portfolio and confirms that the system was evaluated not only under average operating conditions but also during predictable seasonal load peaks.

3.3. Automatic Processing Success Rate

A central operational result of the evaluation is the degree of automation achieved for EDI-originated imports. As reported in

Table 4. Import outcome distribution—EDI orders 2025.

Outcome	Count	Percentage
Fully automatic—no intervention required	1089	87.30%
Blocked—unresolved EAN (new product)	118	9.50%
Blocked—unresolved EAN (data entry error)	24	1.90%
Blocked—city name not resolved	11	0.90%
Failed—malformed XML	5	0.40%
Total	1247	100%

, out of the 1247 EDI import attempts recorded in 2025, 1089 were processed fully automatically, corresponding to an annual automatic processing rate of 87.30%. The remaining 158 imports were blocked or failed due to unresolved product identifiers, address-normalization issues, or malformed XML. This result indicates that the multi-platform architecture achieved high operational viability in live production, despite working across two incompatible proprietary EDI ecosystems.

The temporal evolution of the automatic processing rate is shown in Figure 3. The rate improved monotonically from 71.20% in January 2025 to 94.60% in December 2025, reflecting the cumulative effect of the catalog-enrichment mechanism described in the implementation section. As EAN values and buyer-side product codes were progressively added to the local catalog, later orders containing the same products could be processed without operator intervention. The result is therefore not only a high annual average, but also a clear learning curve over time.

Of the 158 blocked imports, 142 (89.90%) were resolved and reprocessed within the same business day, usually by adding a missing EAN to the product catalog. Only 16 cases required longer resolution involving retailer-side clarification. This shows that most blocked imports were not systemic architectural failures, but manageable catalog-alignment issues occurring during the early operational phase of the platform.

3.4. Error Classification and Resolution

The detailed structure of all blocked or failed imports is summarized in

Table 5. Error classification by type and platform—2025.

Error Type	DocProcess	EDINET	Total	% of Errors
New product—EAN not in catalog	67	51	118	74.70%
Existing product—EAN mismatch (data entry)	14	10	24	15.20%
City name not resolved	6	5	11	7.00%
Malformed XML/encoding error	3	2	5	3.20%
Total	90	68	158	100%

. The dominant error category was new product—EAN not in catalog, with 118 cases, representing 74.70% of all import errors. A further 24 cases (15.20%) were caused by mismatched or incorrectly entered EAN values for already known products. City name not resolved accounted for 11 cases (7.00%), while malformed XML/encoding error accounted for only 5 cases (3.20%). The error distribution therefore shows that the main operational bottleneck was not XML schema incompatibility itself, but incomplete product-master-data alignment.

The platform split of these errors was relatively balanced, with 90 errors attributed to DocProcess and 68 to EDINET. Missing EAN for new products was the largest category in both ecosystems, which suggests that this class of failure is not specific to one platform family, but generic to product-catalog-driven integration. By contrast, the smaller categories provide more direct insight into the consequences of heterogeneous document practices. City-name failures were caused by compound free-text address strings of the form Localitate, Județ that initially fell outside the geographic normalization rules. After those rules were extended, no new city-resolution failures were recorded after May 2025

Malformed XML and encoding errors occurred only in the first quarter of 2025 and were traced to EDINET documents encoded in ISO-8859-2 rather than UTF-8 [22,23]. After a preprocessing normalization step was introduced in February 2025, this error category disappeared entirely. This result is useful because it distinguishes between errors related to master-data maturity and errors caused by format-specific technical friction that can be eliminated through targeted preprocessing corrections.

3.5. Invoice Generation and Submission Outcomes

Invoice-generation and submission outcomes are summarized in

Table 6. Invoice generation and submission outcomes—2025.

Metric	DocProcess Channel	EDINET Channel	ANAF SPV (All Channels)
Invoices generated	668	421	5138
Successfully submitted	651	408	5112
Rejected by platform	17	13	26
Rejection rate	2.50%	3.10%	0.50%
Resubmitted successfully	17	13	24
Final unresolved	0	0	2

. For the 1089 fully processed EDI orders, the platform generated 668 invoices for the DocProcess channel and 421 invoices for the EDINET channel, matching the number of completed orders in each platform family. On the public side, the ANAF SPV received 5138 invoices during 2025, including 668 from DocProcess orders, 421 from EDINET orders, and 4049 from web storefront orders. These values confirm that the platform operated successfully across all three invoice-output paths.

First-pass submission performance was high in all channels, but the ANAF path performed best. As shown in Table 6, rejection rates were 2.50% for DocProcess, 3.10% for EDINET, and only 0.50% for the ANAF SPV path. All 17 DocProcess rejections and all 13 EDINET rejections were corrected and resubmitted successfully within 24 h, while only two ANAF submissions remained unresolved at year-end. According to the manuscript, the lower rejection rate in the ANAF path reflects the stricter pre-validation performed by the SmartBill and Oblio APIs before final SPV submission. Retailer–platform rejections were caused mainly by missing or incorrectly formatted BuyerItemID values, incorrect supplier account identifiers, and empty mandatory XML elements.

This result is notable because it shows that the public invoicing channel was not only legally authoritative, but also operationally more stable than the retailer-facing proprietary channels. In other words, the mandatory public layer was the cleaner machine in the room.

3.6. Processing Time by Channel

Estimated processing time per order is reported in

Table 7. Estimated processing time per order by channel.

Processing Stage	Channel 1 (EDINET)	Channel 2 (DocProcess)	Channel 3 (Website)
Source detection	~0.10 s	~0.10 s	N/A
XML parsing	~0.30 s	~0.20 s	N/A
Product validation	~0.80 s	~0.70 s	~0.10 s
DB persistence	~0.40 s	~0.30 s	~0.20 s
Invoice XML generation	~0.60 s	~0.50 s	N/A
API submission (EDI platform)	~1.20 s	~1.80 s	N/A
API submission (ANAF SPV)	~2.10 s	~2.10 s	~2.30 s
Total automated time	~5.50 s	~5.70 s	~2.60 s
Manual intervention (if needed)	~8–15 min	~8–15 min	None

Note: N/A = not applicable.

. For EDINET-originated orders, total automated processing time was approximately 5.50 s per order, while for DocProcess-originated orders it was approximately 5.70 s per order. For website orders, which bypassed EDI ingestion and retailer-specific invoice generation, the corresponding time was approximately 2.60 s. This means that even in fully automatic mode, EDI-mediated order processing was roughly twice as time-consuming as the direct public e-invoicing baseline.

The additional time in EDI flows was attributable to source detection, XML parsing, product validation, platform-specific invoice generation, and the retailer-facing API submission leg. The manuscript also reports that blocked orders requiring manual intervention typically consumed 8–15 min per case, mostly for EAN lookup, catalog update, and reimport. These timings show that coexistence with proprietary EDI systems imposes both computational and labor overhead beyond the legally necessary invoicing workflow.

3.7. Quantification of Redundant XML Output

The most policy-relevant quantitative result of the study is summarized in

Table 8. XML document generation by type—full year 2025.

Document Type	Count	Recipient	Legal Standing
EDINET Invoice XML	421	EDINET Platform	Commercial acknowledgement
DocProcess DXInvoice XML	668	DocProcess Platform	Commercial acknowledgement
ANAF e-Factura XML (EDI orders)	1089	ANAF SPV	Legally binding
ANAF e-Factura XML (web orders)	4049	ANAF SPV	Legally binding
Total XML documents generated	6227
Legally necessary documents	5138	ANAF SPV
EDI platform-specific overhead	1089	Retailer platforms	None under RO law

, which quantifies XML document generation by type over the full evaluation period. The platform generated 6227 XML documents in total: 421 EDINET invoice XML files, 668 DocProcess DXInvoice files, 1089 ANAF e-Factura XML submissions associated with EDI orders, and 4049 ANAF e-Factura XML submissions associated with web orders. Of these, 5138 were legally necessary ANAF SPV documents, while 1089 represented EDI-platform-specific invoice outputs with no independent legal standing under Romanian fiscal law.

In relative terms, the EDI-platform-specific invoice outputs accounted for 17.50% of the total XML output generated during the year. As the manuscript explicitly notes, this is a conservative quantification because it includes only the XML artifacts themselves and excludes platform subscription fees, development and maintenance costs of the dual parsing and dual invoice-generation architecture, and the labor cost of manual intervention associated with retailer-specific correction cycles. Even in this conservative form, the result shows that a measurable fraction of the supplier platform’s yearly document activity was devoted to generating invoice renderings that duplicated information already validated and stored in the national public infrastructure.

When read together with Table 1 and Table 2, Table 8 becomes especially significant. The 1089 platform-specific invoice XML files did not carry unique fiscal information absent from the ANAF channel; they were alternative structural expressions of substantially the same invoice content for different recipients. The redundancy identified here is therefore not simply a matter of “more files,” but a directly measurable consequence of parallel institutional infrastructures operating on the same transactions

3.8. Synthesis of Main Findings

Taken together, the results support four main findings. First, the three document systems examined in the study exhibit near-complete invoice-content overlap, as shown in Table 1 and Table 2, with the main differences concentrated in structure and identity schemes. Second, the platform operated successfully over a full calendar year, processing 1247 EDI orders and 3891 web orders, with the EDI distribution summarized in Table 3 and the seasonal dynamics shown in Figure 2. Third, the annual automatic EDI processing rate reached 87.30% and improved to 94.60% by year-end, as reported in Table 4 and Figure 3, with most blocking events attributable to catalog incompleteness rather than parser failure. Fourth, the platform generated 1089 proprietary invoice XML artifacts with no independent legal standing, representing 17.50% of the total XML output, as quantified in Table 8.

These results are sufficient to support a strong empirical conclusion: in the analyzed Romanian B2B retail environment, the coexistence of proprietary EDI invoice channels with the mandatory public e-invoicing system creates a technically redundant invoice-output layer. The interpretation of that redundancy—its causes, limits, and implications for interoperability, supplier burden, and ViDA-era convergence—is developed in the next section.

4. Discussion

4.1. Interpretation of the Main Findings

The results presented in Section 3 show that the proposed multi-platform integration architecture is operationally effective in a live supplier environment, achieving a high annual automatic processing rate and improving progressively as the product catalog becomes more complete. However, the technical success of the implementation should not obscure the more important finding that emerges when the comparative and operational results are interpreted together. The architecture is effective precisely because it compensates for a fragmented document ecosystem that no longer appears to be justified by informational necessity.

The evidence summarized in Table 1 and Table 2 shows that ANAF e-Factura, DocProcess, and EDINET carry substantially the same invoice-level business information. The dominant differences concern schema structure, field nesting, and identity conventions rather than the semantic content of the invoice itself. When this finding is read together with the redundancy quantified in Table 8, a more consequential conclusion emerges: a measurable share of the platform’s yearly document-generation activity was devoted to producing retailer-specific invoice XML files that duplicated information already validated and stored in the ANAF SPV. The result is not merely a matter of technical duplication. It is evidence of a two-layer invoicing ecosystem in which the legally authoritative public channel and the retailer-facing proprietary channels coexist over the same transactions without clear informational separation.

This interpretation is consistent with broader literature on digital transformation and inter-organizational integration, which often shows that formal standardization alone does not guarantee effective interoperability when existing institutional arrangements, governance structures, or proprietary platform dependencies remain in place [3,4,5,17,18,21]. Recent work in supply-chain digitalization similarly emphasizes that digital integration can improve performance while still leaving organizations burdened by fragmented infrastructures and uneven cost distribution, particularly in environments where smaller firms must adapt to requirements imposed by larger ecosystem actors [19,24].

A second important interpretive point is that most operational blocking events were not caused by catastrophic incompatibility between XML ecosystems. Instead, they were caused mainly by incomplete product-master-data alignment, especially missing EAN values for new products. This is an important nuance. It means that not every friction observed in the system is evidence against the viability of automation or against the use of structured document exchange itself. Some problems are generic data-governance problems that would exist in many commercial systems. The more distinctive burden created by the current Romanian retail ecosystem lies elsewhere: in the requirement to maintain multiple parser branches, multiple partner-specific identity mappings, multiple invoice-output paths, and multiple validation regimes for transactions that are ultimately already covered by a universal public invoicing channel.

4.2. The Convergence Hypothesis

The central argument of this paper is that the mandatory rollout of RO e-Factura has created the technical and regulatory conditions for a convergent architecture in which the proprietary invoice-reception role of retailer-facing EDI platforms could be reduced or, in some cases, eliminated. This hypothesis rests on three observations established by the preceding sections.

First, informational sufficiency. As shown in Table 1, the ANAF e-Factura document contains the invoice information required by the proprietary retailer-facing invoice channels. The field-level overlap is effectively complete, and the observed differences are primarily structural. From a purely informational standpoint, there is no evidence that EDINET or DocProcess invoice outputs require unique fiscal content absent from the SPV-registered invoice.

Second, universal mandate. Since January 2024, domestic B2B invoices in Romania must be transmitted through RO e-Factura, and ANAF guidance presents this channel as the operational core of compliant invoice transmission for the national B2B environment [11,12,13,14,15]. The SPV is therefore not an optional side channel used by only some suppliers; it is the mandatory baseline for all domestic B2B invoice issuance. ANAF’s guidance also makes clear that the system is intended to function as the national mechanism for electronic invoice exchange and access, which strengthens the argument that invoice duplication across private channels is increasingly difficult to justify on technical grounds.

Third, legal primacy. The SPV-registered invoice is the only invoice representation in the studied ecosystem that carries legal evidentiary weight under Romanian fiscal law. By contrast, the EDINET and DocProcess invoice XML files function as commercial acknowledgements inside private retailer workflows. Once that hierarchy is acknowledged, the architectural asymmetry becomes hard to ignore: the supplier is required to generate additional invoice artifacts for systems whose outputs do not supersede the public legally binding record.

Taken together, these three observations support a convergent model in which the supplier generates a single legally compliant invoice through RO e-Factura, while the retailer retrieves the validated invoice from the public infrastructure rather than requesting a second platform-specific invoice transmission. Such a model would not require the immediate elimination of all proprietary EDI functionality. The order-transmission leg could remain separate for a transitional period. What the results suggest is more specific and more defensible: the invoice leg is already technically over-instrumented.

Beyond the field-overlap analysis, the operational results also provide additional quantitative support for the convergence hypothesis. As shown in Table 6, the ANAF SPV submission path achieved the lowest rejection rate among all invoice-output channels, with only 0.5% rejected submissions, compared to 2.5% for DocProcess and 3.1% for EDINET. In addition, Table 7 shows that website orders, which rely only on the public e-invoicing path, required approximately 2.6 s of automated processing time per order, whereas EDI-mediated orders required approximately 5.5 s and 5.7 s, respectively, because of the extra parsing, validation, XML generation, and retailer–platform submission stages. Together with the 17.5% platform-specific XML overhead quantified in Table 8, these results suggest that the public invoice channel is not only legally authoritative, but also operationally more efficient and more stable than the parallel proprietary invoice-return paths. This does not prove that all proprietary EDI functionality can be eliminated, but it does strengthen the argument that the invoice-exchange layer is already technically duplicative in the analyzed environment.

4.3. Why Convergence Has Not Happened Yet

If the convergence hypothesis is technically plausible, the obvious question is why it has not already occurred. The results of this study suggest that the answer is institutional rather than technical.

The first barrier is institutional inertia combined with sunk investment. Large retail chains have invested heavily in proprietary EDI ecosystems over many years, and those ecosystems are integrated into ERP routines, procurement operations, accounting workflows, and supplier-management processes. Even if the public e-invoicing infrastructure can technically replace part of the invoice-reception role, retailers may see little incentive to modify a functioning internal process whose cost is borne largely by suppliers rather than by themselves. This interpretation is consistent with long-standing EDI adoption literature showing that the burdens of integration are often asymmetrically distributed across the supply chain [3,4,5].

The second barrier is functional asymmetry between order and invoice exchange. RO e-Factura is an invoice infrastructure, not a full procurement-transaction network. It does not replace the order leg of the retailer–supplier relationship. That means that even under a convergent model, some mechanism would still be required for purchase-order transmission, acknowledgements, and possibly downstream logistics documents. In that respect, the paper’s argument is intentionally limited: it does not claim that ANAF e-Factura can replace the entire EDI ecosystem, only that it can plausibly replace the proprietary invoice-return leg. For the order leg, open interoperable infrastructures such as PEPPOL remain a more realistic long-term reference architecture than a state invoice system designed for VAT compliance rather than procurement orchestration [1,2].

The third barrier is asymmetric incentives. In the present ecosystem, the subscription costs, integration-development costs, parser-maintenance costs, and many correction-cycle costs fall primarily on the supplier side. Retailers therefore experience the benefit of receiving standardized data inside their preferred platform without directly experiencing the integration pain imposed on smaller partners. This incentive asymmetry is one of the strongest reasons why technical sufficiency does not automatically lead to ecosystem simplification.

The fourth barrier is transition coordination. Even if one retailer adopted SPV-based invoice retrieval, suppliers would still need to maintain the legacy EDI invoice path for other retailers that did not. In a multi-retailer environment, the benefit of simplification is muted until a critical mass of an actor’s transitions at roughly the same time. This is a classic coordination problem rather than a pure engineering limitation.

A fifth and more pragmatic barrier concerns public API trust and stability. ANAF’s e-Factura infrastructure is operational and has become central to Romanian B2B compliance, but production users have also had to adapt to evolving specifications and implementation changes. For large retailers, a direct-retrieval model becomes attractive only if the public interface is perceived as stable, versioned, and suitable for deep ERP integration. This does not invalidate the convergence argument, but it does mean that technical capability alone is not enough; confidence in long-term operational predictability matters as well.

4.4. Policy and Ecosystem Implications

The findings have implications beyond the narrow technical domain of XML interoperability. At the ecosystem level, the coexistence of mandatory public e-invoicing with proprietary retailer-facing invoice channels represents a structural inefficiency in Romanian B2B digital commerce. The burden of this inefficiency is borne disproportionately by suppliers, especially smaller ones that lack extensive internal IT resources. This observation aligns with earlier literature emphasizing that SME participation in digital supply networks is often constrained less by unwillingness to digitalize than by the cost and complexity of complying with multiple externally imposed integration regimes [3,4,5,19,20,24].

A modest policy response would be for ANAF, together with the Ministry of Finance, to publish a technical recommendation or implementation guideline clarifying that SPV-based invoice retrieval can serve as an acceptable alternative to redundant proprietary invoice submission where both parties agree. Such a step would not require rebuilding the e-Factura system from scratch. The infrastructure already exists. What is missing is a policy signal strong enough to encourage retailers to recognize the public channel as sufficient for the invoice leg.

A stronger response would be to embed this principle more explicitly into future evolutions of the Romanian e-Factura framework. That would create a firmer basis for reducing private invoice-channel duplication when public submission has already been completed. In broader European terms, this logic is compatible with the trajectory of VAT in the Digital Age (ViDA), which was adopted on 11 March 2025 and is being rolled out progressively until January 2035 [14]. The Commission presents ViDA as part of the move toward digitally structured VAT reporting and wider acceptance of electronic invoicing. In that policy environment, the legitimacy of maintaining multiple parallel invoice-reporting channels for the same transaction becomes increasingly weak.

That said, the paper does not support the simplistic conclusion that “the state platform should replace all private systems.” The more defensible implication is narrower and more practical: when a public, mandatory, legally authoritative invoicing system already captures the complete invoice dataset, the continued requirement for suppliers to generate additional private invoice XML outputs should be examined critically and justified explicitly. Without such justification, the extra layer begins to look less like digital coordination and more like ecosystem barnacle growth.

4.5. Generalizability Beyond Romania

Although this study is grounded in the Romanian retail environment, the fragmentation pattern it identifies is not unique to Romania. The broader European move toward mandatory or semi-mandatory e-invoicing has not occurred in a vacuum; it is unfolding in markets where legacy EDI platforms, value-added networks, and retailer-specific procurement infrastructures already exist. The European Commission’s ViDA rollout acknowledges that digital reporting and e-invoicing will be implemented progressively over time, which implies a prolonged transition period in which public infrastructures and private intermediary systems coexist [13,14].

For that reason, the architecture described in this paper may be understood not only as a Romanian case study, but also as a pattern likely to appear in other member states moving from fragmented private document exchange toward more centralized or standardized digital VAT infrastructures. The exact institutional details will differ, but the underlying tension is likely to recur: a state-operated compliance channel becomes universal, while private platforms remain embedded in operational procurement workflows. The question then becomes whether those platforms continue to add unique value or merely preserve historical routing habits.

The discussion also suggests a useful distinction for future comparative research. The problem is not simply “public versus private” infrastructure. The real issue is whether a private layer continues to perform an information-processing function that is not already delivered by the public channel. If it does, it may remain justified. If it does not, its persistence becomes harder to defend on efficiency grounds.

4.6. Limits of Interpretation

The conclusions of this discussion should be read in light of the study’s scope. The empirical evidence comes from a single supplier operating in one product category, and the quantitative evaluation focuses more strongly on workflow success, automation rate, and invoice-output redundancy than on a formal cost model across many firms. The paper therefore does not claim universal market-wide measurement. It offers something slightly different and still valuable: an implementation-grounded demonstration that technical redundancy can be observed directly, measured concretely, and interpreted in policy-relevant terms within a real production environment.

A second limit is that the present convergence argument addresses mainly the invoice-output leg of the transaction. The order-transmission leg remains outside the reach of RO e-Factura and would require either continued use of a procurement network or migration toward a broader interoperable infrastructure. The argument of the paper is therefore not total replacement, but targeted simplification where the evidence already supports it.

5. Conclusions

This paper presented the architecture, implementation, and evaluation of a custom Laravel-based B2B integration platform developed to automate commercial workflows across two proprietary retail EDI platforms, EDINET and DocProcess, together with Romania’s mandatory public e-invoicing infrastructure, RO e-Factura. The study was grounded in a live production deployment and combined comparative XML analysis with operational evaluation over the full 2025 calendar year.

The results showed that the three document systems examined in the study encode substantially the same invoice-level business information, with the main differences concentrated in schema structure, party-identification logic, and institutional role rather than in semantic content. The platform successfully processed 1247 EDI purchase orders and 3891 web orders during the evaluation period, achieving an annual automatic EDI processing rate of 87.30% and improving progressively to 94.60% by year-end through product catalog enrichment. Most blocked imports were caused by incomplete product-master-data alignment rather than by fundamental incompatibility between document ecosystems.

A key finding of the study is that the mandatory public e-invoicing channel already contains the information required by the proprietary retailer-facing invoice channels. During 2025, the platform generated 1089 retailer-specific invoice XML files with no independent legal standing, representing 17.50% of total XML output. This demonstrates that the coexistence of proprietary invoice-return channels with RO e-Factura creates a technically redundant invoice-output layer for suppliers.

The main contribution of the paper is therefore twofold. At implementation level, it demonstrates that heterogeneous retailer document ecosystems can be normalized and automated successfully within a unified internal processing model. At the ecosystem level, it provides empirical evidence that the current Romanian B2B retail invoicing environment imposes avoidable integration complexity on suppliers, particularly on smaller firms with limited IT resources.

The findings support the view that RO e-Factura is technically capable of covering the core invoice-exchange function currently duplicated by proprietary EDI platforms, even if it does not replace the broader order-transmission role of those systems. The barriers to convergence appear to be institutional rather than technical. Future work may extend the analysis to additional supplier environments, broader cost modeling, and comparative studies across other EU member states undergoing mandatory B2B e-invoicing rollout.

Beyond the Romanian retail environment, the findings of this study may also be relevant to other non-retail B2B sectors in which mandatory public e-invoicing infrastructures coexist with legacy private document-exchange platforms. Similar redundancy patterns may emerge in industries such as wholesale distribution, manufacturing, pharmaceuticals, or logistics, where suppliers are often required to comply simultaneously with sector-specific partner systems and state-operated fiscal reporting channels. Although the exact document flows and institutional arrangements differ across sectors, the central issue identified in this paper—the persistence of parallel invoice-processing layers despite the presence of a legally authoritative public channel—may have broader applicability. Future research should therefore examine whether comparable forms of invoice-output duplication, integration overhead, and asymmetric cost allocation can be observed in other industries undergoing digital reporting convergence.