Six conditions for correspondence software to interconnect with government document systems

Many public-sector organizations and state-owned enterprises approach a correspondence-software project with a simple expectation: buy the software, install it, and you can exchange electronic documents with other agencies over the interchange. Reality is more involved. "Interconnecting" with the National Document Interchange Axis, or with a ministry or province's data-integration platform (LGSP) is not a matter of flipping an integration switch. It requires a set of technical, legal and information-security conditions to be met at the same time.

This article lays those conditions out as a checklist. You can use it to audit your current system, or as criteria when drafting a tender and evaluating vendors. What all six share: each one requires the system to be configured and deployed to the organization's specifics, not shipped as a shared boxed product.

A word on who this matters to. If your unit only circulates documents internally, some of these conditions may not apply yet. But the moment you need to send or receive electronic documents with another agency — a ministry, a province, a superior agency — the interchange rules take over, and a system that cannot meet them becomes a dead end. Buyers who discover this late often find they have paid for software that works on its own but cannot talk to anyone else. The checklist below is meant to surface that risk before a contract is signed, not after.

1. The correct document format under Decree 30

Documents in the state administrative bloc follow the format set by Decree 30/2020/NĐ-CP on records management: the national heading, issuing body, document number and notation, summary, recipients, signature and seal each have a defined layout. Electronic documents sent over the interchange must keep that layout to carry the same legal weight as paper.

A system that renders the format incorrectly, or cannot configure the numbering scheme to the unit's records rules, produces documents that have to be fixed by hand before they are issued. The software must therefore configure the format and numbering rules for each unit. This is a mandatory customization, not an optional extra.

2. Packaging documents to the QCVN 102 message standard

This is the piece almost no marketing material mentions, yet it is the technical essence of "interconnection." An interchange document does not travel as a PDF attached to an email. It is packaged into a structured message under national technical standard QCVN 102:2016/BTTTT (issued with Circular 10/2016/TT-BTTTT, amended by Circular 01/2022/TT-BTTTT).

That message contains the sender and receiver identifiers, the document metadata (number, type, abstract, urgency, confidentiality, due date), the body and attachments, and the digital signature. The system must also exchange status messages — received, registered, processed — again in the standard message structure. To join the interchange, the software must implement the correct adapter to QCVN 102 for the specific Axis or LGSP the organization connects to.

3. A valid electronic identifier code

For a document to be routed correctly on the Axis and the integration platforms, the sending and receiving agencies must have valid electronic identifier codes under Decision 20/2020/QĐ-TTg (amended by Decision 09/2025/QĐ-TTg). Without a valid code there is no "address" for the system to route to, and no interconnection.

A timely note: after the 2025 reorganization of administrative units, the identifier catalog changed in many places. The system must be able to update to new codes, and the deployment team must consult the current catalog rather than use old codes.

4. Information security at level three or above

This is the condition many units overlook until they are blocked at the final step. An information system that wants to connect to shared data axes must be secured by level, as required by Decree 85/2016/NĐ-CP. In practice, systems connecting to shared platforms are commonly required to meet level three or above.

Level three is not a certificate on paper. It is a set of real technical requirements: network-zone segmentation, access control, data encryption, and centralized logging and monitoring. An architecture that meets level three almost necessarily sits within infrastructure the organization controls, not on a shared public cloud. In other words, security-by-level has shifted from a paper obligation to a technical precondition for connecting.

5. Connecting over the dedicated data network

The Axis and many shared platforms of state agencies run on the Dedicated Data Transmission Network (Decision 33/2025/QĐ-TTg, replacing Decision 08/2023/QĐ-TTg), separated from the public Internet.

The practical consequence: a system that wants to interconnect directly usually has to be deployed inside that dedicated network — that is, in the customer's infrastructure, on-premise. A service running on a public cloud, in principle, does not sit inside the dedicated network to connect directly. This is an infrastructure argument, not a marketing slogan.

6. Signing with a public-duty specialized certificate

The last condition is often confused. Public digital signatures issued by licensed providers (VNPT-CA, Viettel-CA and the like) suit transactions for businesses and citizens. But documents in the official duties of state agencies use a public-duty specialized digital signature, provided by the certification system of the Government Cipher Committee, under Decree 68/2024/NĐ-CP.

For eOffice software, this means the signing subsystem must integrate the token or key device of the public-duty specialized certificate, not just public signing. This is a separate integration item, and one that many packaged solutions skip.

Why this checklist leans toward customized, on-premise systems

Set the six conditions side by side and a pattern emerges: each requires the system to be configured to the organization's specifics and placed in the organization's infrastructure. Configure the format and numbering. Write the message adapter for the exact Axis or LGSP being connected. Update identifier codes to the actual organization. Build an architecture that meets security level three. Sit inside the dedicated network. Integrate the public-duty specialized certificate.

That is precisely why a system that controls its own configuration and integration code, deployed on-premise, has an advantage over a shared boxed SaaS product. Not because on-premise is abstractly "better," but because it is the form that fits what the law and the real infrastructure actually require.

It also changes how you should read a vendor's promise. "We support electronic document interchange" can mean very different things: a generic feature demo, or a system that has actually met the format, message, identifier, security-level, network and signing conditions for the specific point you connect to. When you evaluate options, ask which of the six conditions each vendor has genuinely satisfied in a comparable deployment, and which they would build during your project. The honest answer to that question tells you more than any feature list.

How Tetra eOffice approaches this

Tetra eOffice is deployed on-premise in the organization's infrastructure, with data under the organization's control, architected toward the application side of information-security level three (central authentication, access control, activity logs), with public digital signing built in via VNPT SmartCA, Viettel MySign and MobiFone HSM. The remaining items are scoped during discovery and built to each unit's requirements: configuring the document format of the bloc the unit belongs to, the QCVN 102 message interconnection to a specific Axis or LGSP, and integrating the public-duty specialized signature. The system needs an Internet connection for users to reach it; for units that must place systems entirely inside a dedicated network isolated from the Internet, the connection approach is reviewed case by case during discovery.

Our approach is not a shared sign-up portal but advising and deploying a system on your own infrastructure, configured to your operations, walking through each interconnection condition above with you and stating clearly what is ready and what needs integration. If your organization is preparing a tender or evaluating options, book a consultation and demo so we can review each condition against your actual system — reach us at contact@tetra.vn.