1. Add the products
Scan barcodes or search quickly. Lines appear with name, price, quantity and total — exactly like a regular cash receipt.
From the same POS screen you use for a regular receipt. A customer asks for a company invoice, you pick the e-Factura option, scan or type the IDNO, and the system automatically fills in the company data from the SFS database, then dispatches the document to the e-Factura SFS portal via API. Signing stays the operator's responsibility per SFS procedure. You never have to go through the SFS portal for day-to-day work.
The flow is designed not to interrupt an ordinary sale — the cashier doesn't leave the POS screen, doesn't open another tab, doesn't have to remember SFS passwords.
Scan barcodes or search quickly. Lines appear with name, price, quantity and total — exactly like a regular cash receipt.
From the fiscal issuance flow, before confirming the receipt, pick the e-Factura option. The rest happens automatically.
Scan the IDNO with the tablet's camera or type it in. The system looks it up in the SFS database and automatically fills in the name, address and tax code — no manual customer data entry.
The system applies the correct TVA rates on each line (8% / 12% / 20% / 0% / no TVA) based on the product, and the invoice number goes up sequentially with no gaps in the series.
With one click the invoice is posted as a draft to the e-Factura SFS portal via API, using the credentials configured in the platform. Signing stays the operator's responsibility per SFS procedure — we only facilitate the dispatch.
In a few seconds you receive a response from SFS. The operator gets notified by having the newly created internal invoice open in the UI, stock is decremented on the invoiced lines, and the SFS journal is updated.
The invoice doesn't just "disappear" after posting — the system tracks its status until it becomes final and flags any action you need to take.
After posting, the invoice moves into one of the following states: Pending acceptance (waiting for the buyer), Accepted (the buyer confirmed → the invoice is final) or Rejected (the buyer refused with a reason — you decide whether to correct and re-send or cancel). The system syncs the status with SFS automatically.
A customer returned the goods, or you discovered a mistake late? The cancellation or reversal request follows SFS procedure and is trackable semi-automatically inside the platform — the system shows the status at every step, and the decision stays with the operator. Full audit: who, when, why.
If SFS refused (rarely — on meta-validations), you get a message with the exact field that doesn't match the format. Fix it → "Re-send" → the flow resumes from posting. No need to rebuild the whole receipt.
Not every B2B is a simple company sale. Here are the documented situations the flow covers.
If the buyer's IDNO doesn't appear in the SFS database, we receive a restriction from SFS and the invoice cannot be issued to that buyer. The fix = the buyer registers, or you pick another sales method (plain fiscal receipt, without e-Factura).
The most frequent case in a small shop: someone comes in and asks for an invoice on the employer's company. The cashier picks between e-Factura (to an IDNO) OR a plain fiscal receipt — you don't issue both on the same document. For e-Factura, scan the IDNO, confirm, a few dozen seconds.
We don't generate a periodic export file. The accountant can pull invoices via the ERP API — with a custom setup we can build, on request, periodic extraction logic in the format preferred by their accounting software (1C, SAGA, BAS, etc.). Individually quoted after evaluation.
We don't issue on your behalf. Signing is done with your user-api credentials dedicated to the e-Factura module, generated separately in the e-Factura SFS portal. Not generic SFS credentials, no USB token for the API — this is the standard method per official documentation.
Configuring the e-Factura credentials in the platform (generating user-api on the SFS portal, connecting to the module) is support effort priced in hours, on request. Alternatively, you can follow our documentation and set it up yourself. Individually quoted after evaluation.
Data from invoices processed through the platform stays in an operational cache on our servers for quick history lookup. The official source is SFS (the e-Factura system); we are not the source of truth. Communication with the SFS API runs over HTTPS with certificate validation.
Every action (issuance, cancellation, reversal, correction) is recorded with who, what, when, why — immutable history. Useful for any tax inspection or discussion with the accountant.
Honesty sells better than broad promises. Here are the real limits of the B2B flow in Small retail.
Signing stays with your credentials. We are the technical channel that automates, not the legal signatory.
Quick invoice confirmation depends on the SFS API being operational. If the SFS API isn't responding, the invoice stays in draft — you re-send it when SFS comes back online.
Bulk-importing invoices previously issued in a different system (for history) is ⚙️ discussed individually — data coming from different systems can be extremely varied in format and structure, so we cannot offer a standard estimate. We discuss it case-by-case after we see the source.
Native export: 1C, SAGA, BAS. Other Moldovan systems — we add the format on request (quoted separately). Custom bidirectional integration = ⚙️ available on request, discussed individually.
Yes. Unlimited, within your package's traffic allowance. We don't bill per document — whether you issue 10 or 500 invoices per month from the shop, the monthly cost (150 MDL) stays the same. Metering is by traffic + storage, generously included in the package.
The difference is the IDNO step + SFS confirmation. The IDNO, scanned or typed, is autocompleted from the SFS database (a few seconds), and the official SFS confirmation arrives in at most 5 seconds under normal conditions. Total: a few seconds added on top of a B2C cash receipt.
The system validates the IDNO against the SFS database. If it doesn't appear (company not registered with SFS), we receive a restriction and the invoice cannot be issued to that buyer. The fix: the buyer registers with SFS, or you pick a plain fiscal receipt (without e-Factura).
Configuring the user-api credentials in the platform (generated separately in the SFS portal) is support effort priced in hours, on request — we quote it in hours after evaluation. Alternatively, you follow our documentation and configure it yourself.
No. e-Factura works stand-alone from the POS. The accountant can pull invoices via the ERP API — with a custom setup we build, on request, the extraction logic in the format preferred by their accounting software (1C, SAGA, BAS, etc.), individually quoted after evaluation. Your data stays available self-service via export at any time.
Technically yes — performance doesn't degrade at volume. But if you consistently have heavy traffic or a large catalogue, the Micro sizing (500 MB storage, 2 GB traffic / month) may become tight and we'd recommend the higher package or add-ons — honestly, at discovery we evaluate this together.
The structures above reflect our standard offer, but every client is discussed individually. We adjust the scope, onboarding timelines and specific configuration based on your business. The binding final offer is the one in the written quote + signed contract.
20 minutes on the phone: we tell you exactly what you need on the SFS side (generating e-Factura credentials), what onboarding looks like, how long it takes to issue the first live invoice from the shop. The Micro package starts at 150 MDL/month, with unlimited e-Factura included. No obligation, no long sales pitch.
We take 20 minutes together to look at your shop — we assess whether SGApps fits your B2B invoice volume, what e-Factura onboarding looks like, and what has to be prepared on the SFS side. The initial consultation is free.
SGAPPS LABS SRL · Chișinău, Moldova · Continuously in production since 2018 · POS · ERP · MEV fiscal register · SFS e-Factura