Connecting Business Central to the SRC e-Invoicing System in Armenia

What is the SRC e-invoicing system, and what does SRC publish for integrators?

The State Revenue Committee runs the e-invoicing system, published in Armenian as "Electronic Settlement Documents" and in English as the Electronic Accounting Documents system. According to the SRC e-invoicing page, it has been in operation since 1 June 2023 and supports electronic issuance of settlement documents under the Tax Code of the Republic of Armenia and Government Decision N1257-N of 5 October 2017. Inside it, a taxpayer can issue, adjust, receive, invalidate, cancel, delete and sign documents, and export them as XML, PDF or Excel. Users reach it through File Online, and anyone can check an issued document by its serial number at e-invoice.taxservice.am.

For software that issues documents directly, SRC publishes an integration package on the same page: API data, XSD schemas and XML templates, updated for the changes that took effect on 1 March 2025. That package is the specification a Business Central integration has to follow, and it is the reference we build and test against. When SRC updates it, the integration is updated with it.

• XSD schemas for tax invoices and for settlement documents.
• XML templates for each document type, in an export form and a signed form.
• API definitions per document type, with the allowed values (enumerations) for fields such as status, VAT rate and transaction type.
• Example calls showing the login and the draft, read and list operations.

Which documents fall under the SRC e-invoicing obligation?

Which documents your company must issue electronically, and when, is set by the Tax Code and depends on your VAT status and the transactions you carry out. Your chief accountant or tax adviser decides that; this page gives no tax advice. What the integration has to support is the set of document types SRC defines in its API package, so that each posted Business Central document lands in the right one.

The SRC package defines two families. Tax invoices cover goods, services, excise goods, leasing acceptance acts and VAT refunds. Settlement documents cover the delivery of goods, the provision of services and works, the transportation of goods, waybills for goods subject to traceability, and exports within the Eurasian Economic Union. During the localization assessment we list the documents your company issues today and map each Business Central document to its SRC type.

How does an invoice travel from Business Central to SRC?

The design keeps Business Central as the source of truth and SRC as the system of record for the tax document. Nothing is retyped in the SRC portal: the AL extension builds the SRC document from the posted Business Central document, so the two can always be reconciled line by line. The steps below follow the operations SRC defines in its integration package.

• Post: the user posts the sales invoice or credit memo in Business Central as usual. Posting rules decide whether the document needs an SRC document at all.
• Map: the extension builds the SRC document from the posted header and lines: supplier and buyer taxpayer identification numbers, names and addresses, supply date, items with unit, quantity, price, VAT rate and amount, and the transaction type.
• Validate: the document is checked against the SRC rules before anything is issued, so data errors are fixed in Business Central rather than in the portal.
• Create the draft: the document is created in the SRC system as a draft, singly or as part of a list.
• Sign: SRC generates the XML to be signed, and an authorised signatory signs it through one of the signing options SRC supports.
• Issue: the signed document is issued, and SRC assigns its serial number.
• Record: the SRC identifier, serial number and status are written back to the posted Business Central document, together with a log entry for every request and response.
• Follow up: later status changes, such as approval by the buyer, cancellation or invalidation, are read back and shown on the same document.

How is the digital signature handled?

SRC documents are signed by a person authorised to sign for the company. The SRC API package defines signing tasks with several options: signing with an ID card, signing with mobile ID, and co-signing. SRC prepares the XML to be signed, the signatory signs it, and SRC tracks the signing task through its own states until the document is signed or the attempt fails.

In our design Business Central never holds a signatory's private key. The extension prepares and queues documents for signing, shows which documents are waiting for a signature, and records who signed and when once SRC confirms it. Which signing option a company uses, and who its signatories are, is agreed with the chief accountant during the assessment, because it changes the daily routine more than any other part of the integration.

Single or batch submission: which should you use?

Both are possible. Besides single documents, the SRC package provides operations to create lists of drafts, to import documents as a batch of XML, and to invalidate documents in a batch, and SRC records whether a document came from the web portal, an import, a batch or the API. A batch returns a result per item, so one bad line does not hide the status of the rest.

Which to use is a business decision. Single submission at posting suits companies that hand the buyer an issued document straight away. A scheduled batch suits higher volumes, such as end-of-day invoicing from a warehouse, where one signatory signs many documents at once. Batch sizes and timing limits are those in the SRC specification for your document types; we set the job queue to stay within them rather than assume a number.

How do statuses and errors come back into Business Central?

Every SRC document has a status, and the SRC package lists them: draft, issued, approved, cancelled, invalid, waiting for acceptance of an invalidation, and deleted. Some documents need approval by the buyer, and a cancellation can need the other party to accept or decline it. The extension stores the current status on the posted Business Central document and keeps the history, so the accountant can see where every document stands without opening the portal.

Errors come back the same way. A validation or technical error is written to the document with the message SRC returned, the document stays in a queue, and it is resent once the data is fixed or the service is available again. A correction after issue is not an edit: in SRC it is a corrector document that increases or decreases the original, and in Business Central it starts from a credit memo or a correction document, so both ledgers tell the same story.

• SRC identifier, serial number and current status on each posted document.
• A request and response log per document, kept for audit.
• A retry queue run by the Business Central job queue, with alerts when a document stays unsent.
• A reconciliation view that lists posted documents with no issued SRC document, and the reverse.

Which fields need Armenian, and what changed on 1 March 2025?

The document carries the parties as they are registered: taxpayer identification numbers, VAT numbers where they apply, legal names and addresses, which for Armenian companies are in Armenian. Item names, units and additional information should be written the way your buyers and the tax authority expect to read them, and SRC defines its own value lists with Armenian labels. The localization stores the Armenian names and addresses on customers, vendors and items, so the document is filled correctly without manual edits.

From 1 March 2025 SRC made a "transaction type" field mandatory in the goods list, as announced in SRC news of February 2025. For tax invoices it offers taxable at the 0% VAT rate, exempt from VAT, and other, and must be filled when the 20% rate is not selected. For settlement documents it offers special tax regime, taxable at 0%, exempt from VAT, not an object of VAT, export, and EAEU export by air, and must always be filled. The localization derives the transaction type from the VAT posting setup in Business Central, so the user does not choose it by hand on every line.

Where does SRC e-invoicing sit inside the Solzet Business Central Armenian localization?

It is one component of a larger set of extensions. Solzet delivers the Business Central Armenian localization: AMD as the local currency, Armenian tax and statutory reporting, an Armenian chart of accounts, Armenian-language documents, and e-invoicing integration with the State Revenue Committee where applicable. Solzet builds it as extensions on the international (W1) version of Dynamics 365 Business Central, which is available in Armenia with localization provided by partners. Microsoft does not ship an Armenian localization, and payroll is not part of what the localization covers.

The e-invoicing component is switched on per company, where that company's obligations require it, so a group can run it in one Armenian company and not in another. What the localization covers and how a project runs are on the Business Central Armenian localization page, also in Armenian and Russian. Further AL work beyond the localization belongs to Business Central AL extension development, and new Business Central projects to Business Central implementation.

We recommend the right solution: Dynamics 365 (Customer Engagement, Business Central or Finance and Operations), Power Platform, or a custom-built CRM. One team for CRM, ERP and the integration between them. For organizations that would rather not carry Microsoft licensing on the CRM side, that includes a custom-built CRM.

What should you prepare before connecting Business Central to SRC?

Most of the work is agreement on rules, not code. A short preparation list saves weeks in testing, and it is the same list we work through in the localization assessment.

• The list of SRC document types your company issues today, with a recent example of each.
• The signatories and the signing option each one uses.
• Who in the company has File Online access and who monitors documents waiting for signature, approval or cancellation.
• Armenian legal names, addresses and identification numbers for customers, and Armenian item names and units.
• The VAT posting setup that decides the VAT rate and the transaction type for each kind of sale.
• A test plan: a full month of real documents, including credit memos, exports and corrections, issued from a test company and reconciled.