Manufacturing EDI in Thailand: 90-Day PoC, Cost & RFP

If your Thai factory is still “re-entering customer purchase orders into the ERP every day,” “creating different shipping notifications for each delivery location,” or “investigating mismatches between invoices and goods receipt results at month-end,” the operational burden is far greater than just the number of documents involved. Even after staff finish manual data entry, if product codes, delivery locations, units, or delivery dates are not aligned with your counterparties, shipment errors and invoice discrepancies will persist. When implementing EDI in manufacturing, the key decisions go far beyond just the communication method. The core is to determine with whom, for which business transactions, using which identifiers and exception handling, and how to enable end-to-end traceability from order receipt through to goods receipt and invoicing.

This article organizes the practical steps from decision-making and quotation requests to 90-day PoC and FAT/SAT for Japanese companies operating factories in Thailand and their local suppliers and customers. To ensure that procurement, sales, logistics, accounting, and IT can use the same evaluation matrix, we treat the five messages—order, response, shipping notification, receipt notification, and invoice—as a single transaction. All numerical examples are hypothetical illustrations to show calculation methods. They are not actual results or market prices.

First Decision: Defining the Scope of “Transactions to Connect via EDI”

EDI is a mechanism for exchanging standardized business documents between companies’ computer systems. GS1 describes EDI as covering purchase orders, shipping notifications, receipt notifications, invoices, and more. However, if you lump together everything from sending purchase order PDFs, manual entry into customer portals, file transfers, to bi-directional integration using standard messages under the single term “EDI implementation,” both quotations and performance metrics become ambiguous. Start by creating a single scope table covering trading partners, locations, product groups, target processes, and exceptions.

If you need to compare the functions of existing order/purchasing systems, refer to How to Select Order and Purchasing Management Systems. This article focuses on message agreements and operational connections between business partners. For a comprehensive overview of API design on the ERP side, see API Integration Development for Manufacturing. While EDI may use APIs as a transport mechanism, the business meaning and counterparty agreement are not determined by the API alone.

Linking Five Messages as “One Order”

A typical workflow involves the buyer sending a Purchase Order (PO), the seller responding with an Order Response or Acknowledgment (acceptance, change, or rejection), sending a Despatch Advice (shipping notification) before shipment, the buyer returning a Receipt Advice (goods receipt notification), and finally reconciling with the Invoice. The specific messages and their names vary by industry and customer requirements, so this sequence should not be treated as a “mandatory standard set for all companies.” In the PoC, prioritize based on where mismatches most frequently occur in your transactions.

It is important not to confuse the “response” with a technical ACK (acknowledgment) from the communication server indicating file receipt. A technical ACK only confirms delivery, not that the seller has accepted the delivery date and quantity. The shipping notification represents the planned or actual shipment, while the receipt notification represents the quantity actually received by the buyer. Maintaining this distinction is essential for reconciling partial deliveries and damages. In the PoC, use the same PO line number across all documents and record the three stages—sending, receiving, and business approval—at separate timestamps.

Aligning the “Meaning” of Item and Location Codes

EDI failures are more often caused by differences in the meaning of the same field names than by unreadable file formats. For example, if the buyer’s “delivery location code” refers to the entire factory, but the seller’s refers to a warehouse gate, simple string mapping is insufficient. In GS1 standards, GLN is used for parties and locations, GTIN for products and services, and SSCC for logistics units. However, not all partners use the same identifiers. Adopt identifiers according to the partner’s implementation guide and agreement, and maintain a mapping table with internal and customer item codes.

The mapping ledger should not be a simple “send field → receive field” table, but should include: (1) business definition, (2) data type and length, (3) required/optional status, (4) code system, (5) conversion rules, (6) source system, and (7) owner in case of exceptions. For quantity and price, always specify units, currency, and tax treatment. For example, converting 1,000 pieces to 100 boxes depends on the number of pieces per box, which may vary by lot or item. If you do not record the packaging master and effective date at the time of conversion, you will not be able to trace the reason for discrepancies later. Decimal points and date time zones should also be included in test data.

Hypothetical Example: If a customer PO specifies item code “A-17”, unit “BOX”, and quantity 12, and your ERP uses item code “P042”, unit “EA”, with an agreed conversion of 1 BOX = 24 EA, the internal requirement is 288 EA. However, the original 12 BOX should also be retained in the order screen so that you can revert to the original meaning for returns, invoicing, or audits. This conversion rate is not based on any actual company’s data. If the number of pieces per box changes due to product revisions, a key based only on item code is insufficient; you must add revision and effective start date as mapping conditions.

In GS1 XML and EANCOM, even the same identifier may have different formatting rules. For example, GS1’s GTIN example uses zero-padding to 14 digits in XML, but variable length in EANCOM. Do not assume “removing leading zeros by numeric conversion is always equivalent”—always check the standard, version, and partner’s implementation guide. You need a mapping ledger that separates message syntax, business field meaning, and partner-specific rules.

Select Format and Communication Method Based on Partner Agreements

Possible options include GS1 XML, GS1 EANCOM, UN/EDIFACT, as well as CSV, XML, JSON, or portal integration specified by your trading partners. While GS1 recommends GS1 XML for new users, if existing partners use EANCOM, you may need to follow that specification. Custom formats may be faster for connecting with a single partner in the short term, but as you expand to multiple partners, mapping branches increase. In your RFP, before locking in a specific method, confirm which versions, implementation guides, communication protocols, and test contacts your partners can accept.

At the communication layer, you may use AS2, SFTP, API, or service provider networks, but successful transfer does not equate to business completion. Do not treat file names or HTTP responses as proof of order completion; manage transmission IDs, correlation IDs, PO numbers, line numbers, versions, processing status, and error reasons. For resends, design idempotency keys to prevent duplicate registration of the same transaction, and define how to handle original and revised numbers for order changes. Regardless of connection method, include operational items such as communication encryption, authentication, certificate renewal, hold queues for partner downtime, resend permissions, and audit logs.

Peppol is a framework of specifications and networks used for e-procurement and e-invoicing. OpenPeppol publishes specifications for Post Award documents such as orders and invoices. However, Peppol is not legally mandatory for all commercial EDI transactions within Thailand. Confirm whether your customer requires Peppol, another network, or a proprietary EDI, and include this in your requirements. Thai e-Tax Invoice should be considered separately as a tax compliance requirement.

Do Not Confuse Thai e-Tax Invoice with Commercial EDI

The Invoice message in commercial EDI is a business document for reconciling billing information with trading partners. In contrast, Thailand’s e-Tax Invoice & e-Receipt is a regulatory framework for electronic documents and transmission for tax purposes. Simply sending an Invoice via EDI does not guarantee that the document meets Thai tax requirements. Conversely, completing tax compliance does not automate the resolution of discrepancies in orders, shipments, and receipts. Even if both reference the same billing data, their purposes, approvers, storage, recipients, and validation items differ.

Specifically, on the EDI side, you must confirm “whether the trading partner could reconcile the PO and invoice lines,” while on the tax side, responsible staff must check the latest requirements of the Thai Revenue Department and ETDA, document formats, signature and transmission methods, and storage. Since regulations and available methods may change, always reconfirm official information immediately before implementation. For tax integration design, refer to Integrating Thai e-Tax Invoice with ERP. In EDI quotations, clearly state whether tax integration is included or excluded; if included, specify tax compliance verification as a separate responsibility item.

Baseline Measurement Before Implementation: Avoid Overstating EDI Benefits

Before estimating that “EDI will eliminate all manual data entry,” first count the current state for each trading partner. Set a target period, such as 4–8 weeks, and collect data on the number of POs and line items, minutes spent on manual entry, number of changes, shipping/receiving discrepancies, invoice discrepancies, and the number of resends or inquiries. If your current process is a mix of paper, email, portals, and existing EDI, record the data by channel. Be sure to include not only the time spent on data entry, but also the time spent investigating discrepancies and confirming with partners. Note that even after EDI implementation, exception approvals and master data maintenance will remain, so do not assume a 100% reduction.

Examples of evaluation metrics include: “Median/90th percentile time from PO receipt to ERP sales order confirmation,” “Percentage of lines requiring manual entry,” “First-pass acceptance rate of messages,” “Matching rate between PO lines and shipping/receiving/invoice lines,” and “Time until unprocessable exceptions reach the responsible staff.” Decide which metrics will serve as success criteria only after measuring the current state and reaching agreement among management, operations, and trading partners. Counting only the number of orders can misrepresent the workload at factories where a single order may have hundreds of lines. Always consider both the number of lines and the number of changes.

How to Run a 90-Day PoC and Deliverables at Each Stage

The 90-day period is not a universal implementation timeline, but an example plan for validating with a single partner, limited items, and limited document types. The duration may be extended or shortened depending on the partner’s readiness and master data quality. Connecting all partners at once can make it difficult to isolate the causes of issues due to overlapping partner-specific exceptions. For the initial PoC, select a partner with a moderate frequency of changes and cooperative staff, and include not only standard cases but also real-world scenarios such as changes and partial deliveries.

FAT (Factory Acceptance Test) is defined as the stage to verify whether conversion and integration work as specified in the provider’s or test environment. SAT (Site Acceptance Test) is defined as the stage to verify usability with actual factories, partners, users, and business procedures. Since names and locations may vary by contract, it is important to specify acceptance criteria in writing in the RFP. Simply rerunning the samples that passed FAT during SAT is not sufficient. SAT should also confirm real-world scenarios such as communication outages, missing master data, long holidays, staff absences, and order revisions.

FAT/SAT Test Cases Must Specify “How to Handle Failures”

Test not only successful order processing, but also duplicate messages, out-of-sequence messages, data overflow, unknown item codes, unknown sites, unit mismatches, price discrepancies, partial shipments, over-shipments, and invoice cancellations. For each, define input samples, expected ERP state, responses to partners, staff notifications, reprocessing authority, and audit logs. If you simply specify “display error,” there is a risk that undelivered messages at night may go unnoticed.

For example, in a test where the same PO number, line number, and revision number message is sent twice, verify that no duplicate order is created on the second attempt, that two communication records remain in the receipt history, and that both are linked to the same business transaction. If a change order arrives before the original order, specify in the requirements whether to hold it, wait for the original, or request a resend from the partner. While automatic resending is convenient, if the partner has already processed the message, it could result in duplicate invoices. Error screens and monitoring notifications should use terminology understandable to procurement, sales, logistics, and accounting staff.

Practical Aspects of Trading Partner Onboarding

The conversion program developed for the first partner cannot always be applied as-is to subsequent partners. Even with a common message format, required fields, product codes, due date handling, attachments, and shipping units may differ. Maintain separate versions of the implementation guide and exception tables for each partner, and manage common conversion rules separately from partner-specific differences. Also record in the connection ledger the notification contacts for specification changes, test environments, certificate expiry dates, incident contacts, operating hours, cutover dates, and parallel operation periods.

At the start of onboarding, prepare a standard checklist. Confirm all at once: business owner, technical contact, accounting contact, adopted message types, samples, identifiers, communication method, change frequency, SLA, and support languages. If a partner cannot support EDI, it is acceptable to allow manual web forms or managed CSV uploads as a transitional measure. However, do not label this as “EDI connected,” and record in your KPIs where manual entry remains. Rather than forcing small suppliers to adopt expensive dedicated connections, it is more practical to have them participate in stages based on transaction volume and required controls.

At go-live, it is also important not to run dual operations of old email orders and new EDI orders indefinitely. Accepting the same PO through both channels risks duplicate registration. Document the parallel period, primary channel, emergency backup procedures, and criteria for discontinuing the old method, and have both parties approve them. By retaining test data and evidence for each new partner added, you can improve the accuracy of estimates for the third and subsequent partners.

Standardizing Quotation Conditions in the RFP

A simple request such as “We want to implement EDI. Please provide a quote” does not allow for proper comparison of initial and monthly costs. The RFP should specify the number of target partners, document types, monthly message volume, peak loads, ERP environment, data quality, required availability, log retention, languages, and scope of tax integration. Attach sample documents with confidential information anonymized, and check internal sharing permissions before releasing actual item codes or trading terms externally.

When comparing, check not only unit prices but also “who and how many days are required to add a new partner” and “which logs can be used to identify the cause after an incident” via demonstrations. Even if “standard support” is claimed, if adaptation to the partner’s guide is charged separately, the total cost will change. Include in your estimate the effort for partner testing coordination, user training, ERP modifications, legal/tax review, and future version upgrades.

Cost Model: Hypothetical Calculation Approach

The following figures are not market prices or TOMAS TECH quotes, but a hypothetical calculation to illustrate the evaluation method. Actual projects will vary significantly depending on partner requirements, ERP modifications, contracts, and communication volume. For example, assume an initial cost of THB 1,200,000, a monthly fee of THB 45,000, an additional partner fee of THB 120,000 per company, with two partners at launch and two more added in the first year. In this case, the first-year cash outlay is 1,200,000 + 45,000×12 + 120,000×2 = THB 1,980,000. Clearly state that this is a hypothetical scenario excluding tax, internal labor, network costs, etc.

Break down the benefits as well. Assume 2,000 POs per month, 8 minutes per PO for data entry and reconciliation, a 70% reduction in this time after EDI, and an internal labor valuation of THB 300/hour. The hypothetical monthly labor benefit is 2,000×8÷60×0.70×300 = THB 56,000. If you further assume that avoiding discrepancy investigations saves THB 35,000/month and avoiding urgent resends and delivery adjustments saves THB 20,000/month, the total monthly benefit is THB 111,000. Subtracting the monthly fee of THB 45,000, the net monthly benefit is THB 66,000. Dividing the initial cost by 66,000 gives a simple payback period of about 18.2 months, but this does not account for partner addition costs, ramp-up period, taxes, working capital, or time value of money, and is therefore insufficient for investment decisions.

Even if work hours are reduced, payroll expenses may not decrease by the same amount immediately. Confirm under what conditions the value can actually be realized, such as reduced overtime, avoided hiring, or increased order processing capacity. When converting reductions in discrepancies or delays into monetary value, multiply the actual number of past incidents by the average handling cost, and do not simply add lost sales opportunities. Prepare three scenarios—conservative, standard, and high-load—and compare total costs over three years, including per-partner addition fees and monthly volume-based charges.

When to Proceed with Procurement, When to Hold Off

Implementation is easier when you have a high volume of documents with the same partner, frequent changes or partial deliveries, manual entry delays that impact production or shipping, a cooperative partner for testing, and clear ownership of master data within your organization. A pilot is advisable if item code mapping by partner is not yet established, order approval workflows are unclear, the cause of invoice discrepancies (tax category or receipt record) is unknown, or ERP input requirements change frequently. These issues cannot be resolved by purchasing an EDI product alone.

If you have “only one partner and just a few orders per month,” managed CSV or portal solutions may suffice rather than full integration from the start. Conversely, if your customer requires electronic shipping notices and discrepancy reconciliation as a procurement condition, consider not only cost-effectiveness but also the risk to ongoing business relationships. Before rushing to a decision, confirm the fallback procedures for reverting to manual processes in case of failure, and clarify where the system of record will reside between systems.

Boundaries Easily Overlooked in Procurement and Implementation Contracts

You cannot delegate all business decisions to the EDI platform provider. Approval rules for purchase orders are the responsibility of the procurement department; confirmation of shipping records falls to the logistics department; discrepancies upon receipt must be handled by the warehouse and quality departments; and accounting and tax classification are the responsibility of the finance and tax departments. The IT department provides mechanisms for connectivity, transformation, monitoring, and access control, ensuring that business decisions are properly recorded. When preparing an RFP, do not simply ask respondents to check “standard feature”—instead, clearly list who updates master data, who approves exceptions, and which costs each task is included in.

The contract should specify the initial implementation scope, unit pricing for adding new trading partners, message version upgrades, incident response times, data ownership, and methods for extracting logs. If the telecommunications provider, transformation provider, and ERP vendor are separate entities, either unify the point of contact for troubleshooting or define the order of contact and response deadlines. Whether delays caused by the partner’s system downtime are considered a breach of your vendor’s availability depends on the measurement point, so clarify this in advance. The service level in the contract should specify exactly which status is being measured—transmission completion, delivery, or business system integration.

During the implementation project, do not assume that familiarity with the purchase order screen is the same as being able to reliably operate based on incoming EDI from partners. Confirm with actual data and responsible staff who has the authority to finalize automatically generated sales orders, who approves changes, and whether shipments can proceed with unresolved exceptions. User training should cover not only operational procedures but also contact points and decision sequences when discrepancies arise. One proof of SAT (Site Acceptance Test) success is when business users can explain these procedures in their own words.

Additional Checks for Multi-Site, Multi-Language Thai Factories

When a Thai factory, Japanese headquarters, overseas customers, and local suppliers are all involved in the same transaction, order times, shipping times, and invoice dates are recorded in different time zones. The system must retain both the timestamp and time zone internally, and display local times according to the user’s site. Define the meaning of “by end of day” in the contract with a clear cutoff time. Since holidays differ by country and factory, do not rely on a single calendar for calculating business days in delivery commitments. For transactions involving import/export, clearly separate the responsibilities for commercial EDI documents and customs documentation.

If local staff operate in Thai, headquarters approve in Japanese, and overseas customers send message specifications in English, translation of error notifications also becomes an operational requirement. However, trading partner codes, item numbers, and status codes must not have different meanings in each language. Store the codes and original values, and map human-readable descriptions to each language. If training materials only contain screenshots, they will quickly become outdated after system changes. Always include the purpose and decision criteria for each operation, and assign responsibility for updating each language version.

When Thai domestic e-Tax documents, overseas customer EDI, and internal ERP intersect, the same invoice number may have different statuses in each system. Do not lump together statuses such as sent, received, tax processed, and payment reconciled into a single “completed” state. When canceling or correcting, confirm with both accounting and sales which statuses need to be reverted and what notifications must be sent to partners. This distinction is necessary not only for reconciling figures, but also for quickly explaining the current status when inquiries arise.

Sample Mapping Ledger: Tracking a Single Purchase Order Line

In actual design, creating only the PO header first does not allow you to measure business value. It is crucial to be able to trace how a single order line is carried through response, shipment, receipt, and invoicing. As a hypothetical example, let’s say the buyer’s order number is “PO-EXAMPLE-01”, line number “10”, buyer item code “A-17”, seller item code “P042”, and order quantity “12 BOX”. If the seller responds, “10 BOX will be delivered on the specified date, the remaining 2 BOX next week,” do not overwrite the order line with a single date. Instead, retain the original request, the two confirmed delivery dates, and the reason for the change. The numbers and quantities shown here are for illustrative purposes only.

If a shipping notice arrives for only the first 10 BOX, save the shipping notice number and shipping detail number against the same PO line. If the warehouse can only receive 9 BOX, the receipt notice should return 9 BOX and the reason for the discrepancy; do not automatically update the ERP receipt record to 10 BOX. Damage or quantity discrepancies also affect quality inspection and reconciliation of accounts payable or receivable. If the invoice arrives for 10 BOX, the responsible staff must decide—based on contract terms—whether to hold, query the difference, or request invoice correction. “Received” and “ready for payment” are distinct statuses. Even just creating a table of these state transitions and getting mutual approval during PoC makes discussions much more concrete.

The mapping ledger should include columns for: partner message fields, internal ERP fields, display names, descriptions, mandatory conditions, allowable values, transformation rules, source of record, reconciliation targets, and error handling procedures. For example, “RequestedDeliveryDate” is not just a date string; whether it means the customer’s desired arrival date at the factory or the supplier’s shipping date determines where it is entered in planning. If “Quantity” has different units for ordering and inventory, both values must be retained. “BuyerParty” and “ShipTo” may be the same legal entity, but the responsible party for billing and delivery may differ. Even if data type conversion is complete, if these meanings are not agreed upon, it is safer not to pass the test.

Decide the system of record for each data element. Who applies for item code conversion, who approves it, and from when does it take effect? When a partner’s address change is received, should the ERP’s partner master be automatically updated via EDI, or should it await approval? Should unit prices be referenced from the procurement contract or should the PO take precedence? If these decisions are hidden in system settings, they cannot be explained when staff change. Link master revision histories to message versions so that the same transaction can be reproduced later.

Operational Design: Who Notices Nighttime Delivery Failures?

While EDI reduces manual data entry, it is not a system that resolves all exceptions autonomously. Operational responsibility must be defined from the very start of the PoC. Distinguish between failures at the sending partner, communications platform, transformation process, ERP integration, and business approval, and assign alerts to the appropriate staff. Simply notifying technical staff of a “file receipt failure” may leave purchase orders unconfirmed, impacting the next morning’s production plan. Procurement and production planning teams need to be shown the business impact so they can prioritize recovery.

Operational manuals should include detection of missed receipts at scheduled times, triggers for resending, contact points for partners, conditions for manual workarounds, and measures to prevent duplicate entries after recovery. If a partner is expected to send orders by a fixed time each day, monitor for non-receipt after that time. For irregular orders, “not received” cannot be immediately classified as an incident; reconciliation with the partner’s transmission confirmation is required. Set monitoring thresholds according to contract and business reality—do not impose a single company-wide standard.

Logs may contain personal information or pricing terms. Do not display all content on a dashboard accessible to everyone; implement access controls and masking according to roles. Retain correlation IDs, timestamps, statuses, error classifications, and response histories as needed for investigation, and align retention periods and deletion methods with contracts and internal policies. Certificate expirations and partner specification changes will occur in operations, so provide advance alerts and time for retesting. At weekly meetings, review not only the number of received messages but also the number and aging of unresolved exceptions.

Quantitative Gates for Rollout Decisions

At the end of a 90-day PoC, do not decide on full rollout just because “it connected”—compare the expected business value with the operational burden. For example, compare initial acceptance rates, time to order confirmation, reduction in manual entry, time to resolve exceptions, and number of invoice discrepancies against baseline figures from before the PoC. If transaction volume or product mix changed during the PoC, explain the impact separately. Do not simply annualize temporary effects seen only during peak periods.

Example rollout gates might include: ① prioritized messages pass both normal and major exception scenarios; ② staff can independently reprocess and communicate; ③ reference numbers remain linked from PO through invoice; ④ responsibilities and maintenance contracts are approved; ⑤ cost estimates for adding each new partner are established. These are recommended evaluation points, not universal pass criteria for all factories. For items with major operational impact, do not waive them based solely on achievement rates—confirm fallback procedures before proceeding.

After go-live, review quarterly the number of exceptions per partner, item mapping corrections, actual operating costs, and days required for additional connections. How much of the standard built for the first partner could be reused for the second will determine future costs. If differences are due to partner-specific requirements, manage them as exceptions; if due to internal item or site master inconsistencies, improve the common side. Do not let PoC “success” end as a one-off event—develop a system that remains manageable as more connections are added.

Frequently Asked Questions

Are EDI and API Integration the Same?

No, they are not the same. EDI handles business documents and semantics agreed between companies, while APIs are one method for systems to exchange data or invoke functions. Some designs transmit EDI messages via API. When selecting, evaluate message contracts and transmission methods separately.

Is Peppol Adoption Mandatory in Thailand?

Do not treat Peppol as a blanket requirement for all commercial EDI. Whether to adopt it depends on partner requirements, target documents, and current regulations. Compare Peppol specifications and Thai e-Tax requirements separately.

Does Sending an Electronic Invoice Fulfill Tax Requirements?

No. Exchanging commercial invoices and meeting the requirements for Thai e-Tax Invoice are separate matters. Tax staff must check current Revenue Department and ETDA documentation to determine required formats, transmission, storage, and audit trails.

What Should Be Estimated First?

Clarify target partners, which of the five document types will be used, monthly transaction and line counts, current ERP and master data status, and number of exceptions. Attach anonymized real data samples and acceptance test conditions to your RFP. Compare not only price, but also costs and operational responsibilities when adding new partners.

Conclusion: Build a Replicable Connection with Your First Trading Partner

The value of implementing EDI in manufacturing is not limited to simply sending purchase orders electronically. The true goal is to enable end-to-end traceability of each transaction—including PO revisions, order responses, partial deliveries, receipt discrepancies, and invoicing—while empowering staff to resolve exceptions efficiently. For your first trading partner, be sure to document the item and site mapping tables, message agreements, monitoring and retransmission procedures, and FAT/SAT evidence. This documentation forms the foundation for scaling EDI connections to additional partners.

At TOMAS TECH, we support requirements definition for Thai factories, covering ERP integration, procurement and sales, logistics, and trading partner connectivity. Even if you have not yet selected products or communication protocols, we can help you organize your current documents, counterpart requirements, and PoC targets. Contact us here.

Reference Information & Primary Sources

• GS1 Ireland: Electronic Data Interchange — Definition of EDI; business messages for ordering, order response, dispatch, receipt, and invoicing.
• GS1: EDI Implementation — Identifiers, and choosing between EANCOM and GS1 XML.
• GS1: EDI Standards — Structure of EDI standards.
• GS1: GTIN format in EDI — Differences in GTIN representation between XML and EANCOM.
• GS1 EDI Business Terms — Standardization of business term definitions.
• OpenPeppol: Post Award Documentation — Specifications for orders, invoices, and related documents.
• ETDA: e-Tax Invoice standard — Thai electronic tax document standards.
• Thai Revenue Department: e-Tax Invoice & e-Receipt — Official portal for system operation.