Getting quotes, invoices and Factur-X out of Tiime Factures

Every issued document in a Tiime account is a Factur-X file: a printable PDF with structured XML welded inside it. That single fact decides most of the integration work, because the thing worth pulling into another system is the XML, not the page. On top of those documents sits a small spine of business records, quotes that become invoices, payment statuses that move over time, a client list, a product catalogue. Tiime, a French company, ships this to self-employed users, freelancers and small companies, and says more than 200,000 entrepreneurs use it. Its own listing and site describe it as an Approved Platform, formerly a plateforme de dématérialisation partenaire (PDP), connected to Chorus Pro for public-sector invoices.

The honest bottom line: this is a document-and-status integration, not a balances feed. You ask for the app and what you want from it; we build a client that signs in with the account holder's consent, walks the quote and invoice surfaces, pulls each Factur-X document with its embedded XML, and tracks the lifecycle statuses as they change. A native Factur-X or PDF export covers the simplest cases, but it loses the status timeline, so we treat it as a backstop rather than the plan.

Records inside a Tiime account

Tiime names its surfaces in French; the table keeps those names so they map cleanly to what you would see in the app.

Ways in, and the one we'd pick

Authorized interface integration / protocol analysis

We observe how the app's own client talks to its backend, under the account holder's authorization, and rebuild the calls that list documents and fetch a single invoice with its statuses. This reaches everything the app itself shows, including the status timeline. It is the most complete route and the one we recommend here. Durability is good as long as we re-validate after major app releases, which we fold into maintenance.

User-consented credential access

Where a workflow needs a hands-off login, we run the client against a consenting account the owner controls. Same reach as above; the difference is operational, around how the session is held and refreshed. Access and any sandbox are arranged with you during onboarding, not a hoop you clear first.

Native Factur-X / PDF export

Tiime can produce the Factur-X document for a client. That is enough when all you need is the compliant file and its core fields. It is the lightest route. It also drops the lifecycle trail and recurring schedules, so we use it to fill gaps, not to carry the whole job.

For most teams the first route is the spine and export is the safety net. We say which one fits once we know whether you care about live status or only the finished document.

What lands in your repo

The headline deliverable is code that runs, not a binder.

• A runnable client in Python or Node.js that authenticates, lists quotes and invoices, fetches a Factur-X document, and reads the status events for one invoice.
• A normalized invoice schema so downstream code sees one stable shape, whichever French invoicing app fed it.
• A status-sync routine with cursor handling, built so a re-run rebuilds the same lifecycle trail instead of clobbering it.
• An automated test suite that pins the request and response shapes the client depends on, so upstream drift is easy to catch.
• Interface documentation covering the surfaces, the auth and token flow, and the Factur-X parsing.
• An OpenAPI / Swagger description of the rebuilt endpoints, plus a short auth-flow and data-retention note, where the engagement calls for them.

A pull against the invoice surface

Illustrative shape of the generated client; field names are confirmed during the build, not assumed here.

from tiime_mirror import TiimeClient   # generated during the engagement

client = TiimeClient.from_consent(token)        # account-holder session, refreshed by the client

# Only what moved since the last cursor
for inv in client.invoices.changed_since("2026-05-01"):
    print(inv.number, inv.total_incl_vat, inv.status)   # "F-2026-0184", 1440.00, "cashed"

    # Each issued e-invoice is Factur-X: a PDF with embedded CII XML
    doc = client.invoices.document(inv.id, fmt="facturx")
    fields = doc.xml.line_items        # qty, unit_price, vat_rate per line — structured, not OCR

    # Lifecycle is event-shaped, never a single overwritten field
    for ev in client.invoices.status_events(inv.id):
        record(ev.code, ev.at)         # deposited / received / refused / cashed

The shape we normalize every record to, so an accounting system reads one contract:

{
  "invoice_id": "string",
  "number": "F-2026-0184",
  "issued_at": "2026-05-14",
  "buyer": { "name": "string", "siren": "string|null" },
  "currency": "EUR",
  "totals": { "net": 1200.00, "vat": 240.00, "gross": 1440.00 },
  "lines": [ { "label": "string", "qty": 1, "unit_price": 1200.00, "vat_rate": 0.20 } ],
  "facturx": { "profile": "EN16931", "embedded": true },
  "status": [ { "code": "cashed", "at": "2026-05-28T09:12:00Z" } ]
}

Where the 2026 reform and GDPR sit

This is a French invoicing app, so two frames apply. The first is the e-invoicing reform. Per the European Commission's reference and the platform write-ups we read, domestic B2B e-invoicing and e-reporting become mandatory from 1 September 2026, with all VAT-registered businesses able to receive from that date and issuing phased by company size into 2027. Invoices move in Factur-X, UBL 2.1 or CII, and each carries lifecycle statuses, four of which (deposited, rejected, refused, cashed) must reach the public portal. Routing runs centrally through the Annuaire by SIREN/SIRET. Tiime sits in this picture as an Approved Platform tied to Chorus Pro, which is why the data we pull already speaks this vocabulary.

The second frame is data protection. The lawful basis we work on is the account holder's own consent to extract their own records, logged and scoped. We minimise what we read, keep consent and access records, and sign an NDA where the work touches client lists or counterparty identifiers. That is how the studio operates, GDPR being the relevant regime here rather than any banking-specific rule.

Things we plan around

Two details on this app shape the build, and we handle both rather than hand them to you.

VAT and rounding across a converted document. Tiime supports several VAT rates on one quote or invoice and converts a devis into a facture in place. We model the per-line tax breakdown and keep a stable link between the quote and the invoice it became, so the mirror neither loses a rate nor double-counts the same revenue once it converts.

Status as a timeline, not a flag. Under the reform an invoice walks through deposited, received, refused and cashed. We capture each transition as a dated event, so reconciliation has the full trail and a late status change does not silently overwrite an earlier one. Where SIREN/SIRET identifiers drive routing, we validate them on the way out so each record carries a usable counterparty key.

How teams wire it in

• AR sync. Mirror issued invoices and their statuses into your accounting or ERP, so the cash position updates without anyone re-typing a number.
• Quote-to-cash tracking. Follow a devis from sent, to accepted, to converted, to invoiced, to cashed inside your own CRM.
• Compliant archive. Pull the Factur-X files for storage with the embedded XML indexed for search and audit.
• Dunning triggers. Fire reminders off documents that are received but not yet cashed, using the status window rather than a guess.

Screens we mapped

Store screenshots we referenced while sketching the surfaces. Tap to enlarge.

How this brief came together

Checked on 2026-06-08 against Tiime's own store listing and Approved Platform page, the European Commission's France eInvoicing reference, and a current write-up of the reform's invoice lifecycle. Where a detail was not published, it is flagged here rather than guessed.

• Tiime Factures — Google Play listing
• Tiime — Approved Platform (ex-PDP) page
• European Commission — eInvoicing in France
• France e-invoicing flow and lifecycle statuses

OpenFinance Lab — interface engineering notes, 2026-06-08

Other invoicing apps in the same orbit

If you are unifying more than one source, these French and international tools sit alongside Tiime and hold comparable records; a normalized schema lets one pipeline read them all.

• Henrri — free quote and invoice tool for freelancers; holds client and document records.
• Indy — accounting and invoicing for the self-employed in France; ledger and invoice data with a connected business account.
• Freebe — invoicing and admin built for French freelancers; quotes, invoices and client files.
• Shine — business account with built-in invoicing; payment and invoice records for micro-businesses.
• Abby — micro-entrepreneur management with invoicing and URSSAF declarations; revenue and document data.
• Facture.net — free online invoicing; quote and invoice documents with customer lists.
• Evoliz — invoicing and pre-accounting for SMEs; structured invoice, payment and ledger records.
• Qonto — business banking with invoicing tools; transactions and issued invoices in one account.
• Invoice2go — mobile invoicing used internationally; per-user invoice, estimate and payment records.

Questions integrators ask

Can the SDK keep a local copy in step as quote and invoice statuses change?

Yes. The client tracks a cursor and pulls only what moved since the last run, and it reads status as a stream of lifecycle events (deposited, received, refused, cashed) rather than one field that gets overwritten. Reconciliation then sees the full history, not just the latest state.

Do you read the Factur-X file itself or only the invoice fields?

Both, but the structured XML is the source of truth. Each issued e-invoice is a Factur-X hybrid: a human-readable PDF with embedded CII XML. We parse the XML for amounts, VAT lines and identifiers, and keep the PDF as the rendered attachment, so downstream systems never depend on OCR.

Does the 2026 French e-invoicing reform change what's reachable?

It adds structure rather than walls. Tiime describes itself as an Approved Platform (formerly PDP) wired to Chorus Pro, so issued documents carry the reform's lifecycle statuses and SIREN/SIRET routing. We map those fields explicitly, since they are what an accounting or ERP system wants to consume.

How soon could a first working Tiime client land?

Most first builds come back inside one to two weeks: a runnable client for the core quote and invoice surfaces, the tests around it, and the notes to maintain it. Scope drives the exact timing, and we confirm it with you before starting.

A first working Tiime client, with its tests and notes, usually lands inside one to two weeks. Source delivered as runnable code starts at $300 and is paid only after it is in your hands and you are satisfied; if you would rather not host anything, our pay-per-call endpoints bill per request with nothing upfront. Tell us the app and what you need from its data at Start at /contact.html and we will scope the build with you, access and compliance included.