Importing a firm's history from another invoicing program

Implemented import readers accept invoice XML/ZIP, SAGA XML, PDF archives and SmartBill unpaid XLSX. They do not connect to SmartBill, Oblio, FGO, Facturis or Keez APIs. A source export's availability is separate from a shipped reader. Imports can carry invoice history, client details and series-number proposals; paid claims never substitute for payment proof. Review the start date and open balances before continuing invoicing. The implementation and its refusal paths are described under “Import scope” below.

The vendor-export research below is dated 2026-11-03. It is background, not a compatibility promise. Items marked unverified require a representative export; no adapter should rely on a vendor menu or API description alone.

What ANAF still gives

• Only the last 60 days. listaMesajeFactura takes zile 1 to 60. In listaMesajePaginatieFactura, startTime "nu poate fi mai vechi de 60 de zile". A download after 60 days fails with "a trecut perioada de 60 de zile". After that ANAF archives the file and posts it again only on request, one invoice at a time, identified by its details (the upload index when known). finrec's sync already uses this window (efactura.inbox.WINDOW). Sources: ANAF e-Factura API (anafpy mirror of the ANAF docs), ANAF RO e-Factura guide, p. 13, fiscalitatea.ro on archiving.
• Nothing in bulk. The SPV web interface has no bulk download of older invoices. Not found: a "Raport e-Factura" or a D394/D406 path that gives the invoices back.
• XML covers part of the history only. RO e-Factura was voluntary for B2B from 2021, and mandatory from July 2022 for invoices to the state (B2G) and for B2B sales of high-risk products (ANAF). Reporting every B2B invoice became mandatory on 1 Jan 2024 (Law 296/2023, art. LIX, fiscalitatea.ro). B2C reporting was optional from July 2024 and mandatory from 1 Jan 2025 (secondary sources only). Firms have had to keep the ZIP since 1 Jul 2024 (contabilul.manager.ro). So a firm may hold older XML (it is a valid import), but for most firms B2B invoices before 2024 and B2C invoices before 2025 have none.
• Message ZIP layout. Each message is a ZIP of two XMLs: the invoice (or ANAF's error list for a rejected upload) and its signature, semnatura_<id>.xml. finrec's parser already reads this (efactura.inbox.invoice_from_zip).

What each program exports

There is no independent market-share data. Vendors claim about 170k firms for FGO, 165k for SmartBill and 150k for Oblio. These figures appear only in a snippet of an aggregator blog that could not be opened. After those three come Facturis Online and Keez, both with public APIs, and SAGA, a desktop accounting program. SAGA matters as the format the others exchange with accountants.

SmartBill

• Rapoarte, Facturi emise: Export Excel (drafts and cancelled invoices left out), Export Saga, Export clienți PF, and Descarcă e-Facturi trimise, which gives the sent XMLs with ANAF's signature. Columns: e-Factura status, Factura, Client, Data emiterii, Data scadenței, Valoare fără TVA, Valoare TVA, Total, Monedă, Status. The client's CUI is not among them. Status is one of Ciornă, Emisă, Depășită, Anulată, Încasată, Parțial. A reversed (storno) invoice also shows as Încasată. (Raport facturi emise, statusuri)
• Facturi neîncasate: Excel with Rest de încasat, the due date and the days overdue. A filter adds the payment date and the amount collected. (structura raportului)
• Export Saga: every invoice shown except cancelled ones. Private-person clients come in their own export. Payments are not mentioned. (export Saga)
• Received invoices: Descarcă e-Facturi preluate gives one ZIP of XML (with the signature) or PDF. It covers at most 100 months, nothing before 1 Jan 2024, and the archive expires the next day. (e-Facturi preluate)
• API (reference, OpenAPI): v1 https://ws.smartbill.ro/SBORO/api, Basic auth with email and token, 30 calls per 10 s, then blocked for 10 minutes. v3 uses a Bearer token (60 reads per 10 s, 50,000 calls a day) and lists clients and suppliers. There is no endpoint that lists invoices. GET /invoice/paymentstatus?cif&seriesname&number gives paidAmount, unpaidAmount and paid for one invoice. GET /series gives each series' nextNumber.

Oblio

• API (docs): POST /api/authorize/token with the account email as client_id and the secret from Setări, Date cont. The token lasts an hour. GET /api/docs/invoice/list lists invoices (series, number, dates, currency, total, client CIF and name), 100 per page, filtered by collected, issuedAfter and issuedBefore. The list carries no paid field: the paid state comes from listing with collected=1, then with collected=0, and withCollects adds the collections to each invoice. Other endpoints: /api/nomenclature/series (start, next), /api/nomenclature/clients (250 per page), and GET /api/docs/einvoice for one invoice's SPV archive. Limit: 30 requests per 10 s.
• Oblio's own migration imports only SAGA XML, as two files, one for paid and one for unpaid invoices, because the file has no paid state (Oblio FAQ). The Import/Export format is not stated.

FGO

• API (test docs): https://api.fgo.ro/v1, auth by an uppercase SHA-1 of CUI + private key (+ number). There is no invoice list. /factura/getstatus gives Valoare and ValoareAchitata for one invoice. There is no series or client endpoint. Limit: 1 request per second.
• Interface (manual): Exportă Excel for a range, with a paid or unpaid filter set beforehand (columns not verified), PDFs in bulk by mail, and a sync with SAGA. Its own onboarding imports issued invoices from SPV for the last 60 days only.

Facturis Online and Keez

• Facturis (API): met: "Facturi", act: "Get" lists invoices by date, with the states Emisă, Plătită, Parțial plătită and Anulată. It also lists clients, collections and received invoices. Auth: API key, user, password and company code in the JSON body.
• Keez (API): GET /{clientEid}/invoices with OAuth. The list has series, number, dates, currency, status (Valid, Draft or Cancelled) and amounts, but no paid field (model).

SAGA XML, the format the others share

(SAGA manual, import date) Invoices come as F_<cif>_<nr>_<data>.xml: <Facturi><Factura><Antet> with FurnizorCIF, the client's name, CIF and IBAN, FacturaNumar, FacturaData, FacturaScadenta, FacturaMoneda and FacturaIndexSPV, then the lines. There is no payment tag; collections are a separate I_<data>.xml (<Incasari>, linked by FacturaNumar). Clients come as CLI_<data>.xml: Denumire, Cod_fiscal, Reg_com, address and Cont_banca. SmartBill, FGO and Oblio all export or import it, and it reaches back before 2024.

Bulk PDF download

• FGO: Facturare → Opțiuni → Descarcă arhiva facturi (monthly archive), documented in FGO's invoice help. The received-invoice archive menu is not pinned by this public page; existing downloaded PDFs are accepted too.

• SmartBill Gestiune documents Documente emise → Facturi → export PDF for the report, not explicitly an archive of individual invoice PDFs, in the issued-document reports help. For received e-Factura copies: Cheltuieli → Preia e-Facturi → Descarcă e-Facturi preluate → PDF (download help). The Facturare-only help does not pin a bulk issued-PDF archive path; use the documented SAGA/XML export or a saved PDF archive rather than assuming Gestiune's menu exists there.

• Oblio: Import/Export → Oblio → Exportă toate facturile una câte una → perioada → Exportă → Descarcă, documented in the bulk-export FAQ. Use individual invoice files. Rapoarte → Raport Facturi → Printează → Salvează ca PDF produces one combined PDF, which stays in review rather than being guessed as one invoice; fiscalm does not split it into invoices.

• SAGA: Ieșiri → Tipărire → Formular PDF also creates invoice XML in TEMP/Facturi, per the manual linked above. Existing client and collection interchange files may be added to the same ZIP.

Import scope

Implemented: finrec history import COMPANY FILE --from YYYY-MM-DD and finrec history list COMPANY [--json], for e-Factura XML and ZIP archives. Mixed PDF/XML ZIP reading and PDF review storage are implemented. The app review table resolves uncertain fields or marks a document as not an invoice. SAGA invoice/client/collection XML is supported in the same upload; SmartBill unpaid XLSX reports can also be uploaded separately; positive unpaid claims can promote the matching history invoice into tracked debt; paid claims remain provenance only. Series proposals already exist in Facturare and require explicit confirmation.

1. One mixed archive: PDFs, e-Factura XML and SPV message ZIPs, detected by content. PDFs reuse the mail reader, accept Romanian suppliers and remain history at every date. Uncertain PDFs wait in a separate review queue, never Sarcini. XML replaces the PDF projection of the same invoice; the original PDF remains stored as its document. AI only narrows rule-found totals through the mail boundary when configured and live. History imports send no document text outside the install in shadow mode.

   e-Factura XML: one file, a ZIP of them, or a ZIP of SPV message ZIPs. Issued and received, told apart by the firm's CUI. It comes from the old program's bulk download (SmartBill gives both sides from 2024) or from the firm's own archive. The ANAF API is no route for history, since it covers 60 days and finrec's sync already reads those.

2. The series' next number, implemented in Facturare, proposed as the highest imported number + 1 and confirmed by the user once every source (XML, SAGA) is in: the XML alone cannot prove a number was never used. Where the old program has an API (SmartBill /series, Oblio next), it can show its number for comparison.

3. SAGA XML, implemented (F_*.xml, CLI_*.xml, I_*.xml), detected by the root, as standalone XML or inside the mixed ZIP. Direction uses the firm's CUI, dates use the same start boundary, and the entire import is transactional and idempotent. Line net amounts plus VAT give the total; nonzero excise totals, non-RON amounts and reverse-charge documents with nonzero TVA remain unreadable rather than guessed, because the manual does not pin their payable amount semantics. Use PDF/e-Factura XML for those documents. Invoice identity requires the same full number, date, kind and firm/supplier as e-Factura; missing series cannot be inferred. Original invoice source is stored once, with digest references from the normalized projections. Client profiles never overwrite reviewed ones; clients without a firm tax identity remain separate incomplete profiles, never merged by name; issuing still requires complete validated details. Collections record provenance only and settle nothing. Missing collections never imply unpaid. SmartBill: Rapoarte → Facturi emise → Export Saga. For FGO/Oblio, use an existing SAGA-format export or obtain the files from the accounting system; their public pages document SAGA interchange but do not pin a direct downloadable XML-export menu in every plan.

4. Unpaid reports: SmartBill XLSX is detected by workbook content and the published Factura, Data emiterii, Rest de încasat columns. It reuses the settlement reader, rejecting formulas, ambiguous headers and a 1904 date system. Reports are uploaded separately after the invoice archive. Claims are retained, never used as collection proof. A positive claim promotes exactly one historical issued invoice with the same full number (separators retained) and issue date, with a source document that is still readable. Missing, ambiguous, duplicate and over-total claims refuse the whole report. Evidence is checked before the write lock, then targets are checked again inside the transaction; concurrent sync cannot add a second open invoice. Zero remaining records provenance and closes nothing. A partial remainder also opens the original full amount: the claimed collected portion is not deducted without bank proof.

   Export and remaining adapters: SmartBill: Rapoarte → Facturi neîncasate → Exportă (Excel/XLSX) (published report structure); save as XLSX if the download is an old binary XLS file. Oblio: an API adapter using collected and series next remains deferred because the product has no Oblio integration/credential boundary yet. FGO: the Excel columns remain unverified after checking its public invoice help and manual on 2026-11-04; no Excel adapter is shipped. Use PDFs or SAGA interchange. Facturis/Keez API readers are not implemented. The unpaid list matters most: until it is imported, the invoices before the start date are history, neither paid nor owed, so the open balances are right from day one only once it is in.

What "paid before the import" means

Every import gives a start date: the day from which fiscalm keeps the firm's payments. The first import sets it, and later imports reuse the same date.

• An XML invoice dated on or after the start date is tracked as if e-Factura sync had brought it. It stays open until a statement shows the payment.
• An XML invoice dated before it, and every PDF-only invoice at any date, is history. It is kept for reports, for the series' numbers and for its client. It is never settled by a statement, never paid, never reminded, and it counts neither as paid nor as owed. An e-Factura XML has no paid state, and another program's "paid" is the user's claim, not proof (AGENTS.md rules 2 and 3).
• History still counts as a rival in the matching. A credit or debit that names a history invoice settles nothing. One that fits a history invoice as well as a tracked one settles neither, because an old invoice paid late must not close a new one. For a recurring client with the same amount every month, this holds back the automatic match for up to a year after the start date, the matching window. A start date from which the bank statements are in keeps that short.
• A supported unpaid list (step 4) turns an identified history invoice into an open, tracked one. That is a debt claimed by the user's own data, the safe direction: it hides nothing. A paid claim only records where it came from. The invoice stays history and nothing is settled.
• If e-Factura sync later brings an invoice that is also in history, the synced one is the one fiscalm tracks.