DESAmedia ·

Short answer

Integration with Rivilė, Directo and Agnum, the most widely used accounting systems in Lithuania, is possible, but each system offers a different route. Rivilė GAMA and Rivilė ERP have a documented REST API available under contract, Directo has an XML interface and a newer API Direct interface with API keys, and Agnum does not publish public API documentation, so the connection is arranged with the vendor or its partner. Where there is no API, file exchange (XML, XLS, EIP) works reliably, provided it is automated, logged and checked.

What integrating with accounting means

Accounting integration is the automatic transfer of data between your accounting software and another of your systems: an online store, CRM, warehouse or production management system. Four types of data are transferred most often:

  • product records, prices and stock levels from accounting to the online store;
  • orders and customers from the online store or CRM to accounting;
  • invoices (usually created in the accounting system, so that numbering and VAT are kept in one place);
  • payments and outstanding balances, so that a sales manager can see in the CRM whether the customer has paid.

Technically, a connection can work in three ways. An API (application programming interface) lets one system query another directly and receive an answer within seconds. File exchange means one system generates a file and the other imports it on a schedule. Direct database access is technically possible, but it bypasses the accounting software's rules, so we only recommend it for reading and only with the vendor's consent.

Before choosing a method, answer two questions: how quickly the data needs to update (in real time, hourly or once a day), and which system is the source of truth for each type of data. The complexity of the connection depends on these answers.

Rivilė integration: options and limitations

Rivilė has two products, and their integrations work differently.

Rivilė GAMA

Rivilė GAMA uses Rivile API v2, a REST interface which, according to the vendor's guide, provides secure access to the database from external systems such as online stores. Requests are sent to a single address (api.manorivile.lt) with an API key in the header, and data can be in XML or JSON. Methods are divided into read (GET_..._LIST) and edit (EDIT_...) types and cover purchases, sales, inventory, the general ledger, payroll, fixed assets and other modules.

A few properties you need to know when designing the connection:

  • An intermediary is required. The API works through a program called Manorivile-Gateway, installed on the client's computer or server with access to the Rivilė GAMA database. If that server is switched off, the API returns a 502 error, so your system must be able to wait and retry.
  • Responses come in pages of 100 records. Reading 5,000 products takes 50 requests.
  • One record per edit request. Bulk updates are done through many separate requests.
  • Billing is per request, regardless of how much data is returned. This directly affects how often you decide to synchronise.
  • The service is purchased under contract with UAB "Rivilė" or its representatives. Prices are not published; they are provided by the vendor or a partner.

Besides the API, Rivilė GAMA supports import and export in EIP file format and has ready-made connectors for Shopify, WooCommerce, PrestaShop, Pigu.lt (a Baltic online marketplace), EDI providers (Edisoft, Telema, Unifiedpost) and point-of-sale systems.

Rivilė ERP

The cloud product Rivilė ERP has a separate REST API with OpenAPI (Swagger) documentation. The API key is created within Rivilė ERP itself. According to the vendor's guide, a single GET request returns at most 100 records, the size of submitted data is limited to 5 MB, and a document can be created with no more than 100 lines at a time. The guide includes examples in PHP, Python, JavaScript and other languages.

Directo: options and limitations

Directo has two integration interfaces.

The XML interface (called xmlcore and XML Direct in the Directo documentation) lets an external system retrieve data (products, customers, stock levels, orders, invoices) and send it to Directo. The data flow is always initiated by the external system, and the response is returned immediately in XML. The documentation states that the interface is not enabled by default and is configured separately for each client, and its setup cost depends on the number of data flows in each direction. As of September 2026, Directo's Lithuanian price list charges €5 per month for exporting XML documents from the Directo database and €25 per month for importing them into it (excluding VAT).

API Direct is a newer REST interface that returns JSON or XML. Access is granted with an API key, managed by a Directo user with SUPER rights (in the settings, under integrations). For each key you can specify which resources and fields it can see, and the openapi.json address shows exactly what that key can do. Data is filtered the same way as in Directo itself, including by modification time, which makes it easy to download only what has changed since the last synchronisation.

Directo's documentation is public and detailed (wiki.directo.ee), which shortens the analysis stage. The main limitation is organisational: until the interface is enabled and the key configured, the developer has nothing to work with, so this needs to be ordered right at the start of the project.

Agnum: options and limitations

On its website, Agnum lists data import from XLS, TXT and XML files, integration with online stores, banks, GPAIS (the Lithuanian packaging and waste register), i.SAF (the VAT invoice register submitted to the tax authority), i.VAZ (electronic waybills), EDI providers (Edisoft, Telema) and "API integrations with external systems". However, as of September 2026 there is no public API documentation on the Agnum website.

In practice, partners connect through the data exchange web service used by Agnum, which transfers orders, product records, prices and stock levels. Its technical specifications, access terms and price are provided on request by the vendor or its partner. So with Agnum the first step is always the same: contact the vendor on the client's behalf and find out which version and configuration is in use and which methods the service supports.

What if you use Site.pro (formerly B1.lt)?

The B1.lt accounting software has been renamed Site.pro. It has public API documentation, a Postman collection and a PHP library. Importing or exporting data through the API requires an active integrations plan.

Comparison

System Interface Documentation Access
Rivilė GAMA REST API v2 (XML, JSON) via Manorivile-Gateway, EIP files Public (gidas.rivile.lt) Contract with Rivilė or a representative, billed per request
Rivilė ERP REST API (OpenAPI) Public (guide.rivile.cloud) API key created in the system
Directo XML interface, REST API Direct (JSON, XML) Public (wiki.directo.ee) Enabled by Directo, monthly fee per data flow
Agnum Web service, XLS, TXT, XML import Not publicly available Through the vendor or a partner
Site.pro (B1.lt) REST API Public Active integrations plan

What to do when there is no API

There may be no API for several reasons: an old software version, a module that has not been purchased, a request-based pricing model that is too expensive, or the vendor simply does not offer one. That leaves file exchange, and it can work reliably if a few rules are followed.

  1. Use the vendor's format. Use an import format the accounting software supports (Rivilė EIP, an Agnum XML or XLS template), not an invented structure. That way the import does not depend on someone "fixing" the file in Excel.
  2. Automate the transfer. The file is generated and placed in an agreed location (SFTP, a shared folder) on a schedule. A person only presses the import button, and it is even better if the accounting software can import on a schedule.
  3. A return file. The accounting system exports a response: which documents were imported and under which numbers. Without it, your system does not know whether an order actually reached accounting.
  4. Be careful with i.SAF. i.SAF is the XML format of the invoice register submitted to VMI (the State Tax Inspectorate). Some programs can import it, but it contains no product lines, so it is only suitable for transferring the VAT register, not for full sales accounting.

Writing directly to the accounting database is a last resort that we avoid: it bypasses the software's rules, and a table structure changed by an update can silently corrupt data.

How data conflicts are resolved

A conflict arises when the same record is changed in two systems, or when one system rejects data from the other. The most common cases and their solutions:

  • One source for each field. It is agreed in advance that prices and stock levels are only changed in accounting, while product descriptions and photos are only changed in the online store. Synchronisation then does not overwrite fields owned by the other system.
  • Code mapping. Rivilė GAMA codes are up to 12 characters long and written in upper case, so an online store's product code does not always fit directly. A mapping table is kept: external ID and accounting code.
  • Protection against duplicate submissions. Each order is sent with a unique external number, and before a document is created the system checks whether it already exists. That way, a request retried after a connection failure does not create a duplicate invoice.
  • Rounding differences. VAT can be calculated per line or on the total, so the online store and accounting totals sometimes differ by 1 cent. The rule is agreed in advance with the accountant.
  • Error log and retries. Every request and response is logged. Temporary errors (server unreachable, timeout) are retried automatically at increasing intervals, while permanent ones (a non-existent product code, a closed accounting period) go to a list reviewed by a responsible person, who is also notified by email.

This kind of logging is useful for more than errors. In the tyre online store with supplier imports we built, every import is logged, so the administrator can see what was updated and what failed without asking a developer.

How long one connection takes

Duration depends more on the number of data types and the direction of synchronisation than on the accounting software itself. Below are indicative engineering ranges, assuming access to the API or import format has already been granted:

Connection type Indicative duration
One-way sync of stock levels and prices 1-2 weeks
Orders to accounting and invoice numbers back 2-4 weeks
Two-way connection with customers, balances and payments 4-8 weeks

These ranges do not include waiting for the vendor to enable a module or grant access. This stage sometimes takes longer than the development itself, so we request access in parallel with the analysis. We also allow time for testing with real data in a test environment: Directo provides an XML demo environment for this, while with Rivilė and Agnum a copy of the database is usually used.

Accounting integration is often part of a larger project. When building a CRM system or an online store, the connection to accounting is worth designing from the start, because it determines how product codes, customers and document statuses are stored in the system.

What to do next

If you are planning to connect your accounting software to an online store, CRM or another system, start with a list: what data needs to move, in which direction and how often. With that list we can assess your case and propose the most suitable approach. You can read more about how we work on our integrations and automation page.

Sources