Splitting an Invoice Batch by the Swiss QR Code Already Embedded in It

Somewhere in your accounts payable inbox right now there's probably a PDF that shouldn't exist as one file. A scanner operator ran forty invoices through a feeder in one pass. An ERP export dumped a month of Swiss QR bills into a single batch. Whatever the source, someone downstream now has to figure out where invoice one ends and invoice two begins, and do it forty more times before lunch.

If those invoices are Swiss, there's a shortcut hiding in plain sight. Every Swiss QR-bill invoice issued since 2020 carries a standardized, machine-readable payment slip as part of the page itself, per the SIX Group Swiss QR standard. That's a structural marker sitting on every invoice in the batch, and PDF4me's Split PDF by Swiss QR endpoint uses it exactly that way: it detects the QR bill boundary on each page and splits the document there. Feed it a 40-page batch of 40 invoices, and you get one PDF per detected invoice back, no page-count parameter, no manual page-range guess.

The documented use cases spell out where this actually gets used: invoice processing, payment processing, document processing, compliance, workflow automation, content management, batch processing, and financial services. Three different upstream sources (a scanner, an accounting export, an ERP job) all landing on the same downstream need.

What the endpoint actually does, and doesn't

This endpoint's job is boundary detection and file separation, full stop. It doesn't read the payment data on the slip, it doesn't validate the QR content against the SIX Group schema, and it doesn't route the resulting files anywhere. If your pipeline needs the creditor, amount, or reference number off each invoice after it's split into its own file, that's a second call to Read Swiss QR Code, which decodes and extracts the structured payment data. Split first, then read each resulting file. Treating those as two separate steps is what keeps a batch pipeline debuggable when something in the middle goes wrong.

The REST page lists six required parameters: File Content (the base64 PDF), File Name, Split QR Page (an enum, after or before, for which side of the detected QR page the cut lands on), PDF Render DPI (enum: 100, 150, 200, or 250, trading recognition accuracy against processing time), Combine Pages With Same Barcodes (a boolean that merges consecutive pages sharing the same QR text into one output document instead of splitting them apart), and Return as Zip (bundle every split file into one archive instead of returning them separately).

The endpoint name has three different answers depending on where you look

Here's something worth knowing before you wire this up. The live REST docs page states the endpoint as POST /api/v2/SplitPdfByBarcode, no "SwissQR" in the route at all. But the official Python sample living in the pdf4me-api-samples repo's own "Split PDF by Swiss QR" folder calls a different route entirely: POST /api/v2/SplitPdfBySwissQR. And that same folder's README describes a third, older generation altogether, one built around manually supplying a barcodeString to search for against a deprecated /api/v2/SplitPdfByBarcode_old endpoint, a shape that doesn't match either the live docs page or the working code sample sitting right next to that README in the same folder.

The code below follows the actual, working split_pdf_by_swiss_qr.py source file, not the stale README next to it, since that's confirmed real code rather than leftover documentation. It also uses that file's real camelCase JSON keys (docContent, docName, splitQRPage, pdfRenderDpi, combinePagesWithSameBarcodes, returnAsZip), which differ from the REST page's UI-friendly table labels the same way this cluster has flagged on several other PDF4me endpoints before. One more gap worth naming: the working sample also sends isAsync, a field the REST page's own parameter table never lists at all.

import requests
import base64

api_key = "YOUR_API_KEY"
base_url = "https://api.pdf4me.com/"

with open("invoice_batch.pdf", "rb") as f:
    pdf_content = base64.b64encode(f.read()).decode("utf-8")

payload = {
    "docContent": pdf_content,
    "docName": "invoice_batch.pdf",
    "splitQRPage": "after",
    "pdfRenderDpi": "200",
    "combinePagesWithSameBarcodes": False,
    "returnAsZip": False,
    "isAsync": True
}

headers = {
    "Content-Type": "application/json",
    "Authorization": f"Basic {api_key}"
}

response = requests.post(
    f"{base_url}api/v2/SplitPdfBySwissQR",
    json=payload,
    headers=headers
)

# 200 = done synchronously, 202 = poll the Location header URL

The response shape is its own open question. The official sample code defensively checks for three different possible shapes: a plain JSON array of {docContent, docName} objects, a {"splitedDocuments": [...]} wrapper whose inner objects use yet another pair of field names (streamFile, fileName), or a single {docContent, docName} object for a one-file result. That's not a guess on this article's part, it's read directly from the sample's own response-handling code, and it's honest enough to be worth confirming against a real request in the interactive Split PDF by Swiss QR API Tester before you commit a parser to one shape.

Same detection, four different integration surfaces

The underlying detection is shared, but the four no-code platforms describe it slightly differently, and it's worth reading their own words rather than assuming they're identical. Zapier separates batch-scanned invoices, payment slips, and utility bills into individual PDFs, with configurable DPI, split position, and ZIP output listed as the available controls. Power Automate covers the same detection inside a Microsoft 365 workflow, with DPI control and merging options listed alongside it. Make frames it as a scenario module for automated payment processing and document routing. n8n covers it as a node for intelligent document organization inside a workflow.

That's four platforms independently naming DPI, split position, and merging as configurable, which is a reasonable signal the underlying engine exposes more than an on/off switch. But those are each platform's own page descriptions, not a parameter table, and this cluster has hit more than one case where a docs page's prose promises something its own configuration UI doesn't actually expose. Confirm the real options against the API Tester or a live test scenario before you build a pipeline on what a page's summary implies.

General REST mechanics, authentication, request and response format, are covered once in Connect to the PDF4me V2 API rather than repeated per feature. Get that base call working once, and the Swiss QR split logic on top of it is a small addition, not a new integration.

None of this requires knowing anything about the invoice's content. It doesn't care about currency, creditor, or amount, because none of that lives in the split step. It cares about one thing: is there a Swiss QR bill payment section on this page. That narrowness is what makes it reliable for exactly the one job it does, and it's why pairing it with a dedicated read step afterward, rather than expecting one call to both split and extract, keeps each part of the pipeline honest about what it's actually responsible for.

Website: pdf4me.com
Documentation: docs.pdf4me.com
Developer portal: dev.pdf4me.com