Moving a Lithuanian public-contract invoice through SABIS

A foreign supplier invoicing a Lithuanian public customer through SABIS should establish how the buyer has registered the contract and the supplier's identity. Electronic delivery alone does not resolve those relationships. A correct-looking invoice can be rejected if its company code or contract number differs from the record against which SABIS is processing it.

The commercial decision is how to connect the actual purchase, the seller named in the invoice and the agreed delivery route. This is particularly relevant to foreign companies because the current SABIS guidance distinguishes their access options from those of users representing Lithuanian-registered organisations.

Confirm the route available to the actual supplier

The SABIS FAQ's foreign-supplier guidance, reviewed on 6 September 2026, describes a current limitation on direct portal access for foreign suppliers and identifies Peppol as a route for submitting their invoices. It also allows a buyer-agreed alternative, such as email, where the stated routes are unsuitable. Do not infer a universal right to choose email independently of the customer.

A supplier should therefore discuss its intended invoicing arrangement with the buyer before the first billing date. State which legal entity is selling, how its accounting provider sends invoices and which identifiers the transmitted message will contain. A vague statement that the company “uses Peppol” leaves the contract and seller matching questions unanswered.

The same FAQ distinguishes foreign residents representing Lithuanian-registered entities from foreign suppliers themselves. The relevant category depends on the organisation represented, not only on the nationality of the employee operating the account. A foreign-owned Lithuanian subsidiary should not automatically adopt the same assumptions as its overseas parent.

This first conversation can remain short when the business already has a suitable invoicing provider. Its purpose is to establish the actual route and the buyer's matching record. It should not become an unnecessary project to recreate the supplier's whole accounting system.

Check the seller recorded against the written contract

The official instruction for registering a contract with a foreign supplier explains the buyer-side process. It specifically warns that the foreign company code must match the code used in the invoices and that the supplier needs the contract number recorded in SABIS. This is a practical dependency between the buyer's preparation and the supplier's billing.

Consider a hypothetical Danish provider of equipment-maintenance scheduling services. Its Lithuanian customer contracted with the Danish parent, while a local representative coordinates delivery. If the buyer registers the representative's company instead of the actual seller, the invoice can fail to match even though the service team and customer understand which work was completed.

The correction begins with the contractual identity. The parties should establish which entity signed the agreement and which entity is entitled to issue the invoice under that arrangement. They can then reconcile the SABIS supplier record and the invoice data. Replacing the seller on an invoice simply to match an incorrect system record would conceal the underlying problem.

Keep the seller's legal name and identifier together in the handover to finance. A group logo or familiar trading name can make the relationship look obvious to a salesperson while leaving accounts staff uncertain about the legal entity. The underlying contract is the stronger reference point.

Preserve the contract number as registered

For written-contract invoices sent through Peppol, the SABIS FAQ says the contract must exist in the system, be linked to the seller and have a number matching the invoice. This means that an internal project label or a shortened contract name may be insufficient even when a human reader recognises it.

The scheduling-services supplier should ask the buyer for the exact registered contract reference before configuring recurring billing. Preserve that value in the customer record along with the source of the instruction. If the buyer changes or corrects the record, finance needs the revised instruction and its relationship to the existing contract.

This is especially important when the parties use more than one reference in ordinary correspondence. A procurement notice identifier, an award reference and a signed contract number may all appear in the account history. They can be retained for their own purposes, but the invoice must carry the identifier required by the actual processing route.

Suppliers already using Lithuania's CVP IS tender and authority workflow should make this an explicit handover after contracting. A tender submission record is valuable evidence of the offer; it does not by itself establish that the buyer has completed every SABIS contract field needed for an invoice.

Distinguish the transmitting operator from the seller

SABIS's Peppol transmission instruction explains that the sender may be another legal entity, such as an operator, while the invoice still identifies the actual seller. It also describes processing or rejection responses reaching the sender where that capability is registered. Agree how those responses will reach the supplier's finance team.

That distinction matters when an accounting provider manages the network connection. The customer may receive an invoice transmitted by the provider, but the commercial claim remains associated with the seller identified in the document. The provider's technical identity should not replace the contracted company's identity in the invoice.

The supplier should also know where to look when something fails. If a rejection message is available only in the provider's dashboard, the account manager may hear that payment is delayed without knowing that the document was rejected earlier. Establish a routine that gives finance the actual response and enough information to investigate it.

A useful first-invoice review compares the buyer's registered seller and contract details with the transmitted invoice and the resulting response. It does not require access to the customer's internal accounting system. The parties can exchange the specific identifiers and status information needed to resolve the transaction through their agreed channels.

Resolve matching errors before repeating the invoice

If an invoice is rejected, identify the mismatch before issuing another document. The seller code, buyer code and contract reference should be checked against the relevant records. A repeated invoice with the same inconsistent data is unlikely to resolve a matching problem and can complicate later reconciliation.

In the scheduling-services example, a rejected first invoice may reveal that the buyer's contract record is still incomplete. The commercial contact can help establish the missing contractual information, while finance and the provider confirm what was transmitted. Each party then addresses the part of the problem it controls.

Once the correction is agreed, retain the earlier response and the relationship to the corrected submission. The supplier should be able to explain whether it changed a data field, the invoice itself or the buyer-side record. That distinction helps prevent a technical correction from being mistaken for a new commercial demand.

Avoid using successful electronic delivery as proof that the invoice has passed every buyer approval stage. Track the actual status available and any remaining substantive question about the billed work. A disputed service period requires the contract and delivery evidence, even if all identifiers match.

Build a repeatable account record

For recurring services, preserve a small set of stable account facts: the seller, the buyer, the registered contract number, the chosen transmission route and the contact responsible for resolving exceptions. Then identify the changing facts for each bill, such as the service period and authorised amount. This separation reduces repeated interpretation without concealing changes.

A company selling across the region will encounter different reference models. The Finnish government invoice guide shows a separate approach to agreement and order identifiers. Keep those customer configurations distinct rather than forcing a single Baltic-Nordic label onto fields serving different purposes.

A dependable SABIS workflow connects the written purchase to the right seller and registered reference, then makes the transmission result visible to finance. That gives a foreign supplier a concrete route from completed work to a traceable payment request, with a clear place to investigate any mismatch along the way.