Extract data from recurring subscription invoices
A recurring subscription invoice is the document a SaaS vendor, a telecom, or a media service raises every cycle for the same account, and what tells it apart from a one-off invoice is the billing period it covers. The amount repeats month after month, but each issue names the service window it charges for, the subscription it belongs to, and the date the next charge falls due, so a revenue team can recognise the fee across the period rather than book it as a single sale. Under the EN 16931 semantic model the document still carries an invoice type code of 380, a single ISO 4217 currency, and the supplier and buyer with their VAT identifiers, yet the fields a subscription-billing system actually reconciles on are the subscription ID, the invoicing period start and end, the next billing date, and the payment status of paid, unpaid, partial, or overdue.
Work sits in the period and the seat-based lines, not the header. Plans billed at a per-seat rate change as seats are added mid-cycle, an add-on such as extra storage is prorated, and a credit from a downgrade lands on the same invoice, so each line keeps its quantity, unit code, net price, and VAT rate rather than collapsing into one figure. VAT has to foot to the tax amount and the payable, the payment means code follows UNTDID 4461 so a SEPA credit transfer is told apart from a card charge, and the remittance information ties the payment back to the invoice. Dunning workflows read the payment status and the due date to decide when to retry a card or suspend the account.
Talonic reads the subscription invoice into the same EN 16931 structure a compliant one-off invoice produces, with the subscription fields kept explicit. An invoice from Helvetia Cloud Services GmbH to Rheintal Marketing GmbH, numbered SUB-2026-0442, covering the period 2026-06-01 to 2026-06-30 with a next billing date of 2026-07-01, returns 25 platform seats and a storage add-on, a 19% VAT breakdown of 212.80 EUR, and a total of 1,332.80 EUR due 2026-06-15 that a billing system posts against the subscription rather than re-keys from a PDF.
What gets extracted from recurring subscription invoices
How extraction works for recurring subscription invoices
Recurring invoices are generated by billing platforms such as Stripe Billing, Chargebee, and Zuora and reach a finance team as PDF renders, portal exports, or email attachments, and each platform lays the period and the plan lines out differently. Talonic classifies the document and binds every value to its EN 16931 business term in the Field Registry, so the subscription ID, the invoicing period start and end, the next billing date, and the payment status resolve regardless of the label the platform printed. Seat-based and prorated add-on lines keep their quantity, unit code, net price, VAT category, and rate, the VAT breakdown is checked to foot to the tax amount and the payable, and the payment means code is read against UNTDID 4461 so a card charge is distinguished from a SEPA credit transfer. Each field returns with a confidence score and a pixel-region pointer conforming to DIN SPEC 91491, so a revenue analyst can verify a period or an amount due against the source before it posts. The extraction structures what the invoice states and does not recognise revenue or compute the tax owed.
Sample extraction
A monthly SaaS subscription invoice with a seat line and an add-on
{
"document_number": "SUB-2026-0442",
"document_date": "2026-06-01",
"invoice_type_code": "380",
"currency": "EUR",
"subscription_id": "SUBSCR-88213",
"invoicing_period_start": "2026-06-01",
"invoicing_period_end": "2026-06-30",
"next_billing_date": "2026-07-01",
"payment_status": "unpaid",
"due_date": "2026-06-15",
"supplier": {
"name": "Helvetia Cloud Services GmbH",
"tax_id": "DE320145887",
"country_code": "DE"
},
"buyer": {
"name": "Rheintal Marketing GmbH",
"tax_id": "DE811990123",
"country_code": "DE"
},
"line_items": [
{
"line_id": "1",
"item_name": "Analytics platform, Business plan",
"quantity": 25,
"quantity_unit_code": "C62",
"item_net_price": 40,
"line_net_amount": 1000,
"item_vat_category_code": "S",
"item_vat_rate": 19
},
{
"line_id": "2",
"item_name": "Additional data storage, 500 GB",
"quantity": 1,
"quantity_unit_code": "C62",
"item_net_price": 120,
"line_net_amount": 120,
"item_vat_category_code": "S",
"item_vat_rate": 19
}
],
"subtotal": 1120,
"total_amount_without_vat": 1120,
"vat_breakdown": [
{
"vat_category_code": "S",
"vat_category_taxable_amount": 1120,
"vat_category_rate": 19,
"vat_category_tax_amount": 212.8
}
],
"tax_amount": 212.8,
"payment_means_code": "58",
"iban": "DE21370501980001234567",
"total_amount": 1332.8,
"amount_due": 1332.8
}Frequently asked
What tells a subscription invoice apart from a one-off invoice?
The billing period and the recurring fields: the subscription ID, the invoicing period start and end, the next billing date, and the payment status. These are captured as discrete fields, because a revenue team recognises the fee across the period rather than as a single sale.
Does it keep per-seat and prorated add-on lines separate?
Yes. Each line keeps its quantity, unit code, net price, VAT category, and rate, so a 25-seat plan line and a prorated storage add-on stay itemised rather than collapsing into one figure.
Is the VAT reconciled to the totals?
Each line is tied to its VAT category and rate, and the VAT breakdown is checked to foot to the tax amount and the amount due, so an invoice whose lines do not reconcile to its stated payable is flagged.
How is the payment status used downstream?
The payment status of paid, unpaid, partial, or overdue and the due date are read as their own fields, so a dunning workflow can decide when to retry a card or suspend an account. The extraction reports the status stated, it does not collect the payment.
What fields are extracted from recurring subscription invoices?
Talonic returns recurring subscription invoices as schema-validated, typed fields. Common fields include Document Number, Invoice Type Code, Subscription ID, Billing Period, and more, each normalized (dates to ISO 8601, amounts as numbers) and mapped to a stable key so the output shape stays the same across layouts.
How accurate is extraction from recurring subscription invoices, and how is confidence reported?
Every extracted cell carries a confidence score from 0.0 to 1.0 and a provenance pointer back to the source page and region, so low-confidence values can be reviewed against the original before the data is trusted downstream. There is no single accuracy number: confidence is reported per field so you can gate on it.
Can I use recurring subscription invoices extraction in production?
Yes. The same engine behind this guide is available as a production REST API and Node SDK with sync, async, and streaming modes, schema versioning, signed webhooks, and EU-resident processing. Start free with an API key, then scale on usage-based pricing.
What does it cost to extract data from recurring subscription invoices?
There is a free tier for prototyping and agent evaluation with no credit card. Paid usage is credit-based at 1,000 credits per euro: page ingestion is 100 credits per page and registry-resolved queries are free. See talonic.com/pricing for current rates.
Ready to extract from your own recurring subscription invoices?
- GDPR
- HIPAA
- ISO 27001 / 42001 aligned
- DIN SPEC 91491 co-author
- EU-resident infrastructure
Author note
Reviewed by Talonic engineering · last reviewed 2026-07-07