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.
Ready to extract from your own recurring subscription invoices?
Author note
Reviewed by Talonic engineering · last reviewed 2026-07-07