Moadian E-Invoicing System (Moadian)
Builds, digitally signs, encrypts and submits sales invoices to the Moadian system, and tracks the status and the tax file of each company. The invoice stays in Sales, and this service is the tax layer.
- Domain
- Tax compliance and connection to the Tax Administration
- Target customers
- Finance and tax departments of financial companies, sales and invoicing teams
- Main capabilities
- Invoice signing and encryption, all seven official patterns, rial-exact calculation, five-layer validation, manual submission, integration with sales
The Moadian service is the layer that connects the platform to the e-invoicing subsystem of the Iranian National Tax Administration. Its job is to build, digitally sign, encrypt and submit sales invoices to the Tax Administration, track their status, and manage each company's tax file, tax memory and signing key. Sales invoices continue to be issued in the group's sales system and the Financial Core stays in the accounting system; this service only adds the tax layer on top of them.
This service is deliberately kept separate from the sales system. Communication with the Tax Administration is an external destination with its own rules for digital signing, serial numbering and an independent inquiry cycle. If this logic sat inside the sales engine, every regulatory change by the Tax Administration would directly affect the issuing of sales invoices, and conversely any outage of the Moadian system would halt invoicing. Keeping the two apart means the business can go on selling even if the tax service is briefly unavailable.
The most important design principle of this system is manual submission: no invoice is sent to the Tax Administration automatically or on a schedule. The reason is simple. An invoice that has been submitted receives a tax number, and it can be withdrawn only by issuing a formal cancellation invoice, so automatic submission of a wrong invoice creates an irreversible tax document. The only automated background process is the status inquiry for submitted invoices, because that only reads and changes nothing.
Key capabilities
Tax file and tax memory for each company
Each company in the group has its own independent tax file and tax memory in the system, and data is never mixed between companies.
Full digital signing key cycle
Key pair generation, certificate request, upload to the Tax Administration's Karpooshe portal, recording of the key ID, activation and revocation. The private key is always stored encrypted and is never visible through a system response or a log.
Support for all seven official invoice patterns
Regular sales, foreign-currency sales, gold and jewelry, contracting, utility bills, airline tickets and exports, each with its own dedicated fields.
Amount calculation engine accurate to the rial
Each line is rounded separately and the header total is built from the sum of the rounded lines, exactly the rule the Tax Administration checks when accepting an invoice.
Five-layer validation before submission
Format and mandatory fields, master data (product code, unit, buyer status), correctness of calculations, invoice-type rules, and submission readiness (key, certificate, memory). All errors are shown at once, in Persian, before any call to the Tax Administration.
Submission only with manual user confirmation
The submit button is always pressed at the operator's own decision; the system never submits any invoice automatically.
Official catalog of goods, services and units of measure
The Tax Administration's official list (close to one million rows) is kept up to date through import of the official file and periodic synchronization.
Automatic and bulk product code mapping
The internal code of each product is linked to the Tax Administration's official identifier. For a large number of products this is done both automatically (exact code match) and in bulk, with a row-by-row error report.
Buyer tax profile and status inquiry
The information the Tax Administration requires about each buyer is maintained, and the buyer's status (active, inactive, unauthorized) can be checked before submission.
Corrective, cancellation and sales return invoices
Correcting or canceling a submitted invoice is always done by issuing a new invoice that refers to the original tax number, never by editing or deleting the original document.
Two-way integration with Sales
Sales invoices without a tax number are identified automatically and prepared for submission, and the tax number and final status are returned to the same sales invoice.
Full tracking of the submission cycle and exchange log with the Tax Administration
From draft to success or failure, every stage and every raw call to the Tax Administration is retained for follow-up and accountability.
Tax reports and dashboard
Submission status, sales summary and tax can be viewed from one dashboard.
Business value
The legal requirement for e-invoicing means real risk for every financial company: a rejected invoice, a blocked buyer or an invalid signing key can halt sales or expose the company to penalties. This system turns submission to the Tax Administration from a manual, error-prone process into a controlled step within the sales flow itself. Its five-layer validation before any contact with the Tax Administration shows problems earlier and more completely than the Tax Administration's own system, which returns only one error per attempt. Rial-exact calculation prevents an invoice from being rejected over a one-rial difference. Separating this layer from sales and accounting means that a change in the Tax Administration's regulations or an outage of the tax service does not stop the company's daily sales operations. Manual submission is also a deliberate compliance choice: final responsibility for submitting any irreversible tax document always stays with a responsible person.
What sets it apart
- Submission is manual by design, as a deliberate compliance decision; no invoice goes to the Tax Administration without the confirmation of a responsible operator.
- Five-layer validation that shows every possible error at once before any network call, unlike the Tax Administration's system, which returns only the first error.
- A signing key cycle with precise protection against activation in the wrong order, the very mistake that in practice causes all of a company's invoices to be rejected at once.
- A rial-exact calculation engine whose output matches the Tax Administration's official kit line by line.
- Direct two-way integration with the sales system, so sales users never have to open another system.
See this module on demo data
In a demo session we walk through your organization's scenarios on Dara's demo environment and answer your technical and finance teams' questions.