DEV Community: Fast Data

Your AI agent found a new IBAN on an invoice. Should it pay? (IBAN checks in Python, and their limits)

Fast Data — Thu, 12 Nov 2026 07:45:33 +0000

An invoice arrives. Same supplier, same amount pattern, but the IBAN is different. If an AI agent prepares your payments, what should it do?

Bank-detail changes are a classic invoice-fraud pattern, and agents make it more interesting: they read every PDF, never get tired and will happily "fix" vendor master data if the instructions say so. So I tested what an IBAN check actually catches.

Disclosure: I built the IBAN Validator & Bank Lookup on Apify, which I use below. The lesson applies to any validator.

The test

Nine inputs: a known-good German IBAN, the same IBAN with one typo, three IBANs where I changed the account number and recomputed the two check digits (what a fraudster would do), plus Dutch, French, Austrian and a truncated one.

import os, requests

URL = ("https://api.apify.com/v2/acts/fast_data_asap~iban-validator-bank-lookup"
       "/run-sync-get-dataset-items")
HEADERS = {"Authorization": f"Bearer {os.environ['APIFY_TOKEN']}"}

ibans = [
    "DE89370400440532013000",        # original
    "DE89 3704 0044 0532 0130 01",   # one digit typo
    "DE62370400440532013001",        # changed account + recomputed check digits
    "DE40370400440532013009",
    "DE18370400440532013017",
    "NL91ABNA0417164300", "FR1420041010050500013M02606", "AT611904300234573201",
    "DE12345",
]
resp = requests.post(URL, headers=HEADERS, timeout=120,
                     json={"ibans": ibans, "includeBankInfo": True})
resp.raise_for_status()
for r in resp.json():
    print(r["input"], r["valid"], r["checksumValid"], r["nationalChecksumValid"], r["bankName"], r["error"])

The result

Input	Valid	MOD-97	National check	Bank
DE89 …013000 (original)	yes	ok	ok	Commerzbank
DE89 …013001 (typo)	no	fails	ok	Commerzbank
DE62 …013001 (changed, recomputed)	yes	ok	ok	Commerzbank
DE40 …013009 (changed, recomputed)	yes	ok	ok	Commerzbank
DE18 …013017 (changed, recomputed)	yes	ok	ok	Commerzbank
NL91 ABNA…	yes	ok	–	ABN AMRO
FR14 2004…	yes	ok	ok	La Banque Postale
AT61 1904…	yes	ok	–	(no bank data)
DE12345	no	fails	–	wrong length

Real output, run on 12 November 2026. Malformed rows are not charged.

Two takeaways:

Typos are caught. The IBAN check digits (ISO 7064 MOD-97) exist exactly for that, and the one-digit typo fails.
Deliberate changes are not. Recompute the two check digits and the IBAN is mathematically perfect. For these three accounts the German national account check passed as well. To every format rule, a fraudulent IBAN at the same bank looks exactly like a real one.

A validator answers "is this a well-formed IBAN, and which bank is it?". It cannot answer "does this account belong to my supplier?".

What the validator is good for in an agent

The useful signal is not valid, it is the comparison with what you already know:

Signal	Source	What the agent should do
`valid: false`	validator	reject, ask for corrected invoice
IBAN differs from vendor master data	your ERP	hold payment, never update master data automatically
`bankName` / `bic` differs from the known bank	validator + ERP	hold, flag as high risk
country of the bank differs from the supplier's country	validator + ERP	hold, flag as high risk
new IBAN confirmed by the supplier through a known channel	human	release

Here is that rule as code:

def iban_decision(invoice_iban: str, vendor: dict, check: dict) -> tuple[str, str]:
    """vendor = your master data, check = one row from the validator."""
    if not check["valid"]:
        return "reject", check["error"]
    if check["iban"].replace(" ", "") == vendor["iban"].replace(" ", ""):
        return "pay", "IBAN matches master data"
    reasons = ["IBAN differs from master data"]
    if check.get("bic") and vendor.get("bic") and check["bic"][:8] != vendor["bic"][:8]:
        reasons.append(f"bank changed: {vendor.get('bank')} -> {check.get('bankName')}")
    if check["countryCode"] != vendor["iban"][:2]:
        reasons.append("bank country changed")
    return "hold", "; ".join(reasons) + " - confirm with supplier via known phone number"

The important design choice: the agent can never move from "hold" to "pay" on its own. It can prepare the evidence (old vs new bank, invoice, sender address), but the release needs a human or a bank-side confirmation.

Verification of Payee does the part a validator cannot

Since October 2025, EU payment service providers have to offer Verification of Payee for euro credit transfers: before you send money, your bank checks whether the payee name matches the account holder of that IBAN and tells you "match", "close match" or "no match". That is the check that would expose the fraudulent IBANs above, because the name on the account would not be your supplier's.

So the full chain for an accounts-payable agent looks like this:

Format and bank (validator): cheap, offline, catches typos and tells you which bank.
Master-data comparison (your system): catches changes.
Verification of Payee (your bank, at payment time): catches wrong account holders.
Human release for every change.

Try it

IBAN Validator & Bank Lookup on Apify: bulk IBAN validation with MOD-97 and national checksums, SEPA flag, bank name and BIC (German banks from the Bundesbank file), $0.0005 per IBAN, runs offline inside the actor. For the full supplier check (company register, VAT ID, IBAN) see our free Agent Skill verify-supplier-de.

This is about payment hygiene, not legal advice.

Question: if you let an agent prepare payments, where do you draw the line: may it ever update vendor bank details, or is that always a human step?

Do countries that shop online also run their firms on AI? I checked 27 EU countries (Eurostat 2025)

Fast Data — Wed, 11 Nov 2026 17:47:58 +0000

I pulled two fresh Eurostat datasets for a short-video series and noticed they look suspiciously alike:

AI in firms: share of enterprises with 10+ employees (excluding the financial sector) that use at least one AI technology, 2025 (isoc_eb_ai).
Online shopping: share of people who bought something online in the last 12 months, 2025 (isoc_ec_ib20, indicator I_BLT12).

Across the 27 EU countries, the two correlate with r = 0.70 (Spearman rank correlation also 0.70). Countries where almost everyone shops online tend to be the countries whose companies use AI.

The numbers

Country	Firms using AI	People shopping online
Denmark	42.0%	91.2%
Finland	37.8%	82.0%
Sweden	35.0%	88.8%
Belgium	34.5%	78.5%
Netherlands*	33.2%	94.2%
Germany	26.0%	81.4%
EU average	20.0%	73.6%
Ireland	19.6%	95.1%
Czechia	17.6%	83.7%
Italy	16.4%	56.2%
Poland	8.4%	69.7%
Romania	5.2%	60.3%

*Eurostat flags the Netherlands' 2025 AI value as a break in series. Dropping it changes r from 0.70 to 0.68.

Three things that stood out

1. The Nordic block sits near the top on both. Denmark, Finland and Sweden are in the top right corner. Denmark's 42.0% means more than two in five firms use some AI technology, roughly double the EU average of 20.0%.

2. Ireland is the big outlier. 95.1% of people bought online in 2025, the highest share in the EU, but only 19.6% of firms use AI, just below the EU average. Without Ireland the correlation rises from 0.70 to 0.77. My guess (and it is only a guess): Irish consumers buy heavily from platforms based abroad, while the AI question is asked of firms located in Ireland. The two indicators measure different populations, and Ireland makes that visible.

3. Germany is middle of the pack on AI, above average on shopping. 26.0% of German firms use AI (about one in four) and 81.4% of people shop online. Both are above the EU average, but well behind the Nordics.

What this does not show

Correlation, not causation. A third factor (income, digital skills, broadband, company size structure) likely drives both. I did not control for anything.
"Uses AI" is a yes/no question. A firm that uses one chatbot counts the same as one that runs its whole planning on machine learning.
No trend claims. I only compare 2025. The list of AI technologies in the survey can change between years, so year-over-year jumps need care.

Getting Eurostat data into Python without pain

Eurostat's API returns JSON-stat: values come as a flat, sparse dictionary keyed by a single index, and you have to unfold that index into the dimensions yourself. This is the helper I used (standard library only):

import json, urllib.parse, urllib.request

API = "https://ec.europa.eu/eurostat/api/dissemination/statistics/1.0/data/"

def eurostat_rows(dataset, **filters):
    url = API + dataset + "?" + urllib.parse.urlencode({"format": "JSON", "lang": "EN", **filters})
    with urllib.request.urlopen(url, timeout=60) as resp:
        d = json.load(resp)
    ids, sizes = d["id"], d["size"]
    codes = {k: {i: c for c, i in d["dimension"][k]["category"]["index"].items()} for k in ids}
    rows = []
    for key, value in d["value"].items():
        k, row = int(key), {}
        for dim, size in reversed(list(zip(ids, sizes))):  # last dimension changes fastest
            row[dim] = codes[dim][k % size]
            k //= size
        row["value"], row["flag"] = value, d.get("status", {}).get(key)
        rows.append(row)
    return rows

ai = eurostat_rows("isoc_eb_ai", indic_is="E_AI_TANY", size_emp="GE10",
                   unit="PC_ENT", nace_r2="C10-S951_X_K", sinceTimePeriod="2025")
shop = eurostat_rows("isoc_ec_ib20", indic_is="I_BLT12", ind_type="IND_TOTAL",
                     unit="PC_IND", sinceTimePeriod="2025")

Two gotchas cost me time:

Gotcha	Symptom	Fix
A wrong filter code	the response has a dimension of size 0 and no values, no error	check `d["dimension"][dim]["category"]["label"]`; for firm size it is `GE10`, not the label text
Ignoring `status`	you silently compare provisional or broken series	keep the `flag` column (`p` provisional, `e` estimated, `b` break in series) and decide per row

The full helper is in our public repo: snippets/eurostat_table.py.

Try it

Disclosure: I build data tools for AI agents as Fast Data on Apify; this article uses only Eurostat's free API and needs none of them. If you work with European business data, our open data-recipes repo has the snippet above plus n8n workflows and Agent Skills for public tenders, supplier checks and e-invoices.

Question: what would you control for first to see if the AI/online-shopping link survives: income per head, broadband coverage, or the share of large companies? And does anyone have a better explanation for Ireland?

Your invoice is dated on a Saturday. Which ECB exchange rate do you use? (Python)

Fast Data — Wed, 11 Nov 2026 12:55:00 +0000

Here is a USD 1,250 invoice dated Saturday, 7 November 2026. What is it worth in euros?

The ECB publishes no reference rate on Saturdays. So your code either crashes, silently uses some other day, or asks a human. And the day matters more than people expect: between 2 and 10 November, the same USD 1,250 was worth between €1,109.43 and €1,119.57 depending on which daily ECB rate you pick.

That is up to €10.14 on one mid-sized invoice, from rate-day choice alone, and even the two neighbouring fixing days (Friday vs Monday) differ by €2.80. Across a few hundred invoices a month, "we just used the rate from somewhere" gets hard to reconcile for whoever closes the books.

Disclosure: I built the ECB Exchange Rates – Invoice Currency Converter on Apify, which the code below uses. The rules in this post apply to any implementation.

The four decisions behind every conversion

Decision	Options	Actor default (your policy may differ)
Which rate source?	ECB reference rate, bank rate, a "mid-market" API	ECB reference rate (public, reproducible)
Which day?	invoice date, delivery date, payment date	invoice date
No rate that day?	previous fixing day, next fixing day, fail	previous fixing day, flagged
Which rounding?	per line, per invoice, half-up, banker's	half-up to 2 decimals, keep the unrounded value

The third row is where homemade scripts often go wrong. The ECB publishes its euro reference rates for about 30 currencies on TARGET working days, around 16:00 CET. No rate on weekends, none on TARGET holidays such as 1 January or Good Friday, and none for today until the afternoon.

Converting a batch of invoices

import os
import requests

URL = ("https://api.apify.com/v2/acts/fast_data_asap~ecb-exchange-rates-invoice-converter"
       "/run-sync-get-dataset-items")

invoices = [
    {"id": "INV-1001", "amount": 1250.00, "currency": "USD", "date": "2026-11-07"},
    {"id": "INV-1002", "amount": 480.50,  "currency": "GBP", "date": "2026-11-05"},
    {"id": "INV-1003", "amount": 2999.90, "currency": "CHF", "date": "2026-10-30"},
]

HEADERS = {"Authorization": f"Bearer {os.environ['APIFY_TOKEN']}"}

resp = requests.post(
    URL,
    headers=HEADERS,
    json={"mode": "convert", "items": invoices, "targetCurrency": "EUR", "fallback": "previous"},
    timeout=120,
)
resp.raise_for_status()

for row in resp.json():
    if row["status"] != "ok":
        print(row["id"], "ERROR:", row["error"])
        continue
    flag = f"  <- rate of {row['rateDate']}" if row["fallbackUsed"] else ""
    print(f"{row['id']}: {row['amount']} {row['currency']} = {row['convertedAmount']} {row['targetCurrency']} "
          f"(rate {row['rate']}){flag}")

Real output of that input:

INV-1001: 1250 USD = 1119.57 EUR (rate 1.1165)  <- rate of 2026-11-06
INV-1002: 480.5 GBP = 576.19 EUR (rate 0.83393)
INV-1003: 2999.9 CHF = 3262.89 EUR (rate 0.9194)

Each row also carries daysShifted (here -1), convertedAmountUnrounded (1119.57008509) and a sourceUrl that returns exactly the ECB observation that was used:

https://data-api.ecb.europa.eu/service/data/EXR/D.USD.EUR.SP00.A?format=csvdata&startPeriod=2026-11-06&endPeriod=2026-11-06

That URL is the audit trail. Store it next to the booking and anyone can check the number later without trusting your code.

What the three fallback rules give you

Same invoice, USD 1,250 on Saturday 7 November, three settings:

`fallback`	Rate day used	Rate	EUR
`previous`	Fri 6 Nov	1.1165	1,119.57
`next`	Mon 9 Nov	1.1193	1,116.77
`none`	–	–	error row, so a human decides

previous is the actor's default because that rate was already published on the invoice date. next can make sense if your policy is "first rate published after the document". none is right when you would rather stop than guess. The bad option is the one many scripts implement by accident: no rule at all.

Three gotchas I hit while building it

1. The ECB quotes "units of foreign currency per 1 EUR". 1.1165 means 1 EUR = 1.1165 USD, so USD → EUR is a division: 1250 / 1.1165. Multiplying gives you €1,395.63 and a very confused accountant.

2. Cross rates go through the euro. There is no ECB USD/GBP rate. USD → GBP is amount / rate(USD) * rate(GBP), with both rates from the same fixing day. Mix a cached rate for one currency with a fresh one for the other and your cross rate quietly comes from two different days.

3. Fetch per currency, not per invoice. One request per invoice is slow and impolite to a free public API. Group by currency, request the whole date range once, then look up each invoice locally. The actor sends one ECB data request per currency per run (plus retries on errors), however many invoices you pass.

If you only need the rates

The rates mode returns the daily series instead:

resp = requests.post(URL, headers=HEADERS, timeout=120,
                     json={"mode": "rates", "currencies": ["USD", "JPY"],
                           "startDate": "2026-11-02", "endDate": "2026-11-10"})
resp.raise_for_status()
for row in resp.json():
    print(row["date"], row["currency"], row["rate"], row["status"])

For 2 to 10 November that is 7 fixing days per currency (the weekend is simply missing), for example USD 1.1216 on 2 November and 1.1214 on 10 November. An unknown code such as XYZ comes back as one error row instead of crashing the run.

What this is not

Not tax advice. The ECB itself says its reference rates are for information purposes only. For VAT, some countries prescribe other rates (in Germany, for example, the Federal Ministry of Finance publishes monthly average rates, based on the ECB rates, under § 16 (6) UStG). Ask whoever signs your tax return which rate applies.
Not affiliated with the ECB. The actor only reads the ECB's public Data Portal API.
Not a trading rate. Your bank converted the actual payment at its own rate. The difference is usually booked separately as an FX gain or loss; your accountant decides how.

Try it

ECB Exchange Rates – Invoice Currency Converter on Apify: $0.001 per result row (converted amount or daily rate), error rows are free, no API key for the ECB needed. It pairs with our XRechnung & ZUGFeRD parser: take currency, grandTotal and issueDate from a parsed e-invoice and convert it here. AI agents can call it as an MCP tool: https://mcp.apify.com?tools=fast_data_asap/ecb-exchange-rates-invoice-converter.

Question: which rate day does your team use for foreign-currency invoices: invoice date, delivery date or payment date? And has an auditor ever asked you to prove where a rate came from?

How to screen company names and domains against BaFin warnings in Python, and the false positive you will hit first

Fast Data — Wed, 11 Nov 2026 07:48:26 +0000

If you onboard merchants, pay suppliers or approve affiliates in Germany, one cheap check is: is this firm or website on a current warning from BaFin, the German financial regulator?

BaFin publishes these warnings as news items: unauthorised banking, clone websites, fake job offers, plus fines and other measures. There is no screening API. So I wrapped the public feeds into one, and this post shows how to call it from Python, and what the results look like on real data.

Disclosure: I built the BaFin Warnings actor on Apify. The routing logic below works with any warning source.

What the data looks like

I keep a daily snapshot of BaFin's German RSS feeds. The four snapshots from 8 to 11 November contain 36 notices, published between 9 October and 10 November:

Type	Notices
Supervisory measures (fines, own-funds requirements, orders)	22
Consumer warnings (unauthorised firms, clone sites, fake jobs)	14
... of which name at least one website domain	11

The measures are mostly against licensed institutions, so they are a different signal from the warnings. For screening new counterparties, the 14 consumer warnings are the interesting part. They break down into unauthorised business (7), identity theft (4), fake job offers (2) and one general warning.

Two of the 14 had no usable firm name in the feed text alone: one is about a WhatsApp group, the other title quotes the scam sites' advertising slogan. The actor opens each warning page to fill these gaps; my offline archive only has the feed, which is why the numbers here are a lower bound.

The script

Screen mode takes names, domains or full URLs and returns one row per hit, or one matched: false row per name:

import os, requests

ACTOR = "fast_data_asap~bafin-investor-warnings"
URL = f"https://api.apify.com/v2/acts/{ACTOR}/run-sync-get-dataset-items"

def screen(queries, min_score=85):
    r = requests.post(URL, params={"token": os.environ["APIFY_TOKEN"]}, timeout=120,
                      json={"mode": "screen", "queries": queries, "minScore": min_score})
    r.raise_for_status()
    return r.json()

def route(hit):
    if not hit.get("matched"):
        return "pass"
    if hit["matchedOn"].startswith("domain:") and hit["matchScore"] == 100:
        return "block"          # the exact website is named in a warning
    if hit["warningType"] == "identity_theft":
        return "review"         # see the next section
    return "review" if hit["matchScore"] < 100 else "block"

for hit in screen(["https://www.meinallianz.com/login", "Landshypotek Bank", "Example Trading Ltd"]):
    print(route(hit), hit["query"], hit.get("matchScore"), hit.get("matchedOn"), hit.get("url"))

Names are normalised before matching: legal forms like GmbH, Ltd or AG are dropped, example(.)com obfuscation is resolved and URLs are reduced to their domain. Exact domain hits score 100.

Real results

I ran the same matching code offline against the 36 archived notices:

Query	Score	Matched on	Warning type
`meinallianz.com`	100	domain `meinallianz.com`	identity theft
`https://www.klever-beratung.de/jobs`	100	domain `klever-beratung.de`	fake job offers
`Klever Beratung GmbH`	100	name `Klever Beratung`	fake job offers
`klever-beratung.com` (other TLD)	95	name `Klever Beratung`	fake job offers
`Landshypotek Bank`	97	name `landshypotek-bnk`	identity theft
`allianz.de`	74	name `meinallianz`	identity theft
`Example Trading Ltd`	48	(no hit)

The first four rows behave the way you want.

The false positive you will hit first

Look at Landshypotek Bank. Landshypotek is a real Swedish bank. The BaFin warning is about landshypotek-bnk.com, a website that pretends to be that bank. Screening the real bank's name scores 97, above the default threshold of 85.

This is not a matching bug. It is how identity-theft warnings work: the fraudulent site copies a legitimate name on purpose. The better your fuzzy matching, the more reliably the real firm matches the warning about its impostor. 4 of the 14 warnings in my sample are of this type, so you will see it early.

The fix is in the routing, not in the threshold:

Exact domain hit: block or escalate. The website itself is named by the regulator.
Name hit on an identity_theft warning: send to a human, and check which domain the counterparty actually uses. Here, landshypotek.se scores only 81 against the fake domain, under the threshold.
Name hit on other warning types: review. A different TLD (.com vs .de) can be the same operation or an unrelated firm.

Raising minScore to 98 would hide the Landshypotek row, but it would also hide the .com variant, which is exactly the kind of near-miss you want a person to look at.

Coverage, said plainly

The feeds cover recent weeks, not a full archive. In my snapshots, the oldest notice was about a month old. If you need history, run list mode daily and store the rows.
A missing hit means "not in current warnings", not "licensed". Licences are checked in BaFin's company database, which this does not query.
Natural persons are never returned: names of people in warnings are replaced with [name redacted].
It is a technical lookup, not legal advice. Every hit links to the BaFin page, which is the authoritative source.

Cost

Use	Price
Screen one name or domain	$0.01
Daily list of new warnings (20 rows)	$0.04

A weekly re-screen of 200 active merchants costs $2.

Try it

BaFin Warnings Scraper on Apify: list mode for monitoring, screen mode for your own names and domains. Also usable from n8n or as an MCP tool for AI agents.

Question: if you run counterparty checks, how do you handle impersonation warnings: by domain only, manual review, or an allow-list of known legitimate firms?

I added 10 validation rules to an e-invoice parser without changing one existing warning. Here is the test setup

Fast Data — Tue, 10 Nov 2026 17:48:55 +0000

The validation output of my e-invoice parser had a design flaw: it was a list of English sentences.

"validationWarnings": ["Tax basis + VAT = 1728.70, but grand total is 1729 (BR-CO-15)"]

Fine for a human. Bad for an accounts-payable workflow that wants to block on real errors, only log hints, and show the user which field is wrong. The only way to do that was to parse the strings. And once output is published, it is an API, whether you like it or not.

So this week's job was: add machine-readable findings and more rules without changing a single existing string, because any workflow built on the old output has to keep working.

Disclosure: I built the XRechnung & ZUGFeRD Parser on Apify. This post is about the testing approach, which works for any parser.

The new shape

Every finding now has a rule ID, a severity and the business term it refers to. The message is exactly the old string.

"validationFindings": [
  {"rule": "BR-04",    "severity": "error", "field": "BT-3",   "message": "Missing required field BT-3 type code"},
  {"rule": "BR-CO-15", "severity": "error", "field": "BT-112", "message": "Tax basis + VAT = 1728.70, but grand total is 1729 (BR-CO-15)"},
  {"rule": "BR-CO-16", "severity": "error", "field": "BT-115", "message": "Grand total - prepaid + rounding = 729.30, but amount due is 729 (BR-CO-16)"}
],
"errorCount": 3,
"warningCount": 0

That is real output for a UBL credit-note sample from the Mustang project's test files. validationWarnings is still there and still a list of strings.

The safety net: old code vs new code on public invoices

I did not write new unit tests first. I froze the old module and compared it with the new one on real files, a golden-master test:

import glob, importlib.util, os, sys

def load(name, path):
    spec = importlib.util.spec_from_file_location(name, path)
    mod = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(mod)
    return mod

old, new = load("old", sys.argv[1]), load("new", sys.argv[2])
bad = 0
for path in sorted(glob.glob(os.path.join(sys.argv[3], "*"))):
    if not path.endswith((".xml", ".pdf")):
        continue
    data = open(path, "rb").read()
    o, n = old.parse(data), new.parse(data)

    # 1. every old warning must still be there, same text, same order
    old_w, new_w = o["validationWarnings"], n["validationWarnings"]
    prefix_ok = new_w[: len(old_w)] == old_w

    # 2. every other old field must be unchanged
    diff = [k for k in o
            if k not in ("validationWarnings", "validationWarningCount") and o[k] != n.get(k)]

    if not prefix_ok or diff:
        bad += 1
        print(os.path.basename(path), "prefix_ok =", prefix_ok, "diff =", diff)
print("files with differences:", bad)

Two rules do the work:

Old warnings are a prefix of the new list. New checks may only append. This forces the code structure too: the historical checks stay in one block in their original order, new checks come after it.
Every old field is equal. New fields are allowed, changed ones are not.

The test data is public

No customer invoices needed. Two open sources cover most real-world shapes:

the KoSIT XRechnung test suite: 66 standard cases in UBL and CII syntax (invoices, corrections, self-billing),
sample files from the Mustang project: 7 files including a ZUGFeRD PDF, a Factur-X MINIMUM file and a UBL credit note.

What the run showed

Result on 73 public files	Files
Old output identical, no findings	70
Old output identical, findings unchanged (now with rule IDs)	2
Old output differs	1

The one difference was a good catch. For CII invoices I had added contactDepartment to the existing seller object, because rule BR-DE-5 accepts a department name as contact point. A new key inside an existing object is still a diff. It is additive, so I kept it, but I only knew about it because the script compares whole objects and not just the fields I had in mind.

The two files with findings:

File	Findings
Mustang `ubl-creditnote.xml`	BR-04, BR-CO-15, BR-CO-16 (all error)
Mustang `facturFrMinimum.xml`	BR-CO-16 (warning)

All 66 KoSIT standard cases produce zero findings, which is what you want from a rule set: valid invoices stay quiet.

Quiet files prove nothing about new rules though, so I derived four variants from one KoSIT case, three of them deliberately broken:

Own test file	New findings
Credit note (381) without reference	FD-PRECEDING (warning)
Credit note (381) with reference	none, `precedingInvoice` = `{number: "123456XX", date: "2016-04-04"}`
Deliberately broken XRechnung (UBL)	BR-CO-16, BR-DE-6, BR-DE-9, BR-DE-23-a
XRechnung CII without seller contact	BR-DE-2

Three decisions that mattered more than the code

Severity depends on the profile. A Factur-X MINIMUM file is not a full EN 16931 invoice by design. Reporting its missing fields as errors would make every such file "broken". So missing EN fields are errors for full profiles and warnings for MINIMUM and BASIC WL. That is why the same rule (BR-CO-16) appears as error in one row above and as warning in the other.

Never invent an official rule number. The IDs were checked against the public KoSIT and EN 16931 Schematron files. For my own plausibility checks, such as "credit note without a preceding invoice reference", I use a private prefix (FD-...) instead of borrowing a BR number that says something slightly different.

Say what it is not. This is a set of plausibility checks, not a Schematron validation. An invoice with errorCount: 0 can still be rejected by the official validator. That sentence is now in the README, next to the rule table.

One gap the test did not close

On the CII file without a contact, BR-DE-7 (seller e-mail) stays silent: the parser has always filled the e-mail from the electronic address when its scheme is EM. Changing that would alter an existing field, so rule 2 of the test says no. It is in the backlog as a documented limitation instead of a silent behaviour change.

Takeaways

Published strings are an API. Freeze them and add structure next to them.
A short old-vs-new script over public sample files finds what you did not think of.
Valid files must stay quiet; you need deliberately broken files to see new rules fire.

Try it

The parser turns XRechnung (UBL/CII) and ZUGFeRD/Factur-X PDFs into JSON with the findings above, for $0.003 per invoice: XRechnung & ZUGFeRD Parser on Apify.

Question: how do you keep old output stable when you extend a parser or an API: golden files, contract tests, something else? And have you been bitten by "additive" changes that still broke a consumer?

How to check a new supplier's company data (LEI, register number, VAT) with Python before the first payment

Fast Data — Tue, 10 Nov 2026 12:44:57 +0000

Before a new supplier gets paid for the first time, someone in finance usually does the same three checks by hand: Does this company officially exist? Is the VAT number valid? Who is behind it? Each answer lives in a different place, and none of them is fun to copy-paste.

Two of those places are official and free to query:

GLEIF, the global registry of Legal Entity Identifiers (LEI): legal name, legal form, register number, addresses, status and parent companies.
VIES, the European Commission's service that confirms whether an EU VAT number is valid.

This post shows a short script that runs both checks for a whole supplier list and returns one row per company with warning flags.

Disclosure: I built the EU Company Check (KYB) actor used here. It only queries the official GLEIF and VIES APIs: no register scraping, no data about people.

Why bother: one in five German LEIs has lapsed

I asked the official GLEIF API today (10 November 2026):

Scope	LEIs
Worldwide	3,489,248
Germany (legal address)	259,636
Germany, status ISSUED (renewed)	186,894
Germany, status LAPSED (not renewed)	55,763

A lapsed LEI is not proof of anything bad, but it means the company stopped confirming its data every year. Combined with a VAT number that VIES does not recognise, it is a good reason to pick up the phone before you pay.

The script

# pip install apify-client
import csv, os
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_TOKEN"])

suppliers = [
    "SAP SE; DE143454214",          # name + VAT number after a semicolon
    "Siemens Healthineers AG",      # name only
    "HRB 719915",                   # German register number
    "Nonexistent Testfirma XYZ GmbH",
]

run = client.actor("fast_data_asap/dach-company-kyb-official").call(run_input={
    "companies": suppliers,
    "country": "DE",          # filter matches to German entities
    "includeParents": True,   # add direct and ultimate parent
})
rows = list(client.dataset(run["defaultDatasetId"]).iterate_items())

with open("supplier_check.csv", "w", newline="", encoding="utf-8") as f:
    w = csv.writer(f)
    w.writerow(["query", "legalName", "registeredAs", "lei", "registrationStatus", "ultimateParent", "vatValid", "flags"])
    for r in rows:
        parent = (r.get("ultimateParent") or {}).get("legalName", "")
        vat = (r.get("vat") or {}).get("valid", "")
        w.writerow([r["query"], r.get("legalName"), r.get("registeredAs"), r.get("lei"),
                    r.get("registrationStatus"), parent, vat, "; ".join(r.get("flags", []))])

needs_review = [r for r in rows if r.get("flags")]
print(f"{len(rows)} checked, {len(needs_review)} need a human look")

The input accepts a name, an LEI or a register number and detects which one it is. A VAT number can follow a semicolon.

What came back

This is the real result of a test run on 10 November 2026:

Query	Legal name	Register no.	LEI status	Ultimate parent	VAT	Flags
SAP SE; DE143454214	SAP SE	HRB 719915	ISSUED	–	valid	Multiple matches (2) - showing 1
Siemens Healthineers AG	Siemens Healthineers AG	HRB 237558	ISSUED	Siemens Aktiengesellschaft	–	–
HRB 719915	SAP SE	HRB 719915	ISSUED	–	–	–
Nonexistent Testfirma XYZ GmbH	–	–	–	–	–	No match

Three things worth noticing:

The parent company comes for free. Siemens Healthineers shows Siemens AG as direct and ultimate parent, with its LEI. That is the question procurement teams ask most often and the hardest one to answer by hand.
"No match" is a result, not an error. The made-up company returns a row flagged No match (and is not charged), so your list stays complete and the gap is visible.
Even big names get flagged. GLEIF has two records with the exact legal name "SAP SE". The actor picks the active, issued one and tells you it had a choice. Register numbers are not unique across German register courts either, which is why the country filter matters.

The flags, and what to do with them

Flag	What it means	Typical next step
`No match`	Nothing in GLEIF for this name/number	Ask the supplier for its LEI or register extract
`LEI lapsed (not renewed)`	Company stopped confirming its data	Check if the company is still active
`Fuzzy name match - verify`	No exact name, closest full-text hit shown	Compare address and register number
`VAT invalid`	VIES does not confirm the VAT number	Do not pay before clarifying
`Name differs from VAT name`	VAT number belongs to a differently named entity	Check for typos or a different group company
`Multiple matches (n)`	Several records fit	Add the register number or LEI

The point is not to block payments automatically. It is to let the 90% of clean rows through and put the rest in front of a person.

Running it on every new supplier

Two easy ways to make this routine:

In your ERP export: run the script nightly on suppliers created that day and post rows with flags to Slack or e-mail.
For AI agents: the actor is available through Apify's MCP server, so an accounts-payable agent can call it before it proposes a payment. Our MCP setup lists it in the finance pack.

For a fuller check, combine it with an IBAN validation and a screen against BaFin warnings.

Limits

Only companies with an LEI are in GLEIF. Many small businesses never needed one, so No match for a local craftsman is normal.
This is not a commercial register extract, a credit check or legal advice. It confirms identity data from official sources; the decision stays with you.
VIES depends on national systems and is sometimes unavailable; the actor flags VAT check unavailable instead of guessing.

Cost

$0.004 per company found; rows without a match are free. Checking 100 new suppliers a month costs at most $0.40.

Try it

EU Company Check (KYB) on Apify

Question for finance and procurement folks: which check do you do first when a new supplier shows up, and which one has actually caught a problem for you?

How to get EU public tenders from TED as JSON in Python (without learning expert-query syntax)

Fast Data — Tue, 10 Nov 2026 07:44:38 +0000

Every public tender above the EU thresholds, from a German city's software project to a French hospital's equipment purchase, is published in TED (Tenders Electronic Daily), the EU's official procurement journal. TED has a free, official search API. The catch is its expert query syntax, its nested multilingual fields and a single notice that can contain several lots with different deadlines and values.

This post shows a script that answers one practical question: "Which open tenders match what we sell, in the countries we serve, and are still biddable?" You get flat JSON and a CSV.

Disclosure: I built the EU Tenders (TED) API actor used below. It calls the official TED Search API v3 and only returns organisations, never contact persons.

The 20-line version

# pip install apify-client
import csv, os
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_TOKEN"])

run_input = {
    "keywords": ["software"],
    "countries": ["DEU", "AUT"],      # ISO alpha-3 buyer countries
    "cpvCodes": ["72", "48"],         # IT services, software packages
    "noticeTypes": ["competition"],   # open calls for tenders
    "publishedWithinDays": 7,
    "deadlineAfter": "today",         # skip expired tenders
    "maxResults": 50,
}

run = client.actor("fast_data_asap/eu-tenders-ted-api").call(run_input=run_input)
notices = list(client.dataset(run["defaultDatasetId"]).iterate_items())

notices.sort(key=lambda n: n.get("deadline") or "9999")
fields = ["deadline", "buyerName", "buyerCity", "buyerCountry", "title", "estimatedValue", "currency", "url"]
with open("tenders.csv", "w", newline="", encoding="utf-8") as f:
    w = csv.DictWriter(f, fieldnames=fields, extrasaction="ignore")
    w.writeheader()
    w.writerows(notices)
print(len(notices), "open tenders written to tenders.csv")

No browser, no HTML parsing. The actor turns the inputs into a TED expert query, follows pagination and flattens each notice into one row.

What comes back

These are real rows from test runs on 8 and 9 November 2026 (shortened):

Deadline	Buyer	What	Est. value
02.12.2026	MD-IT GmbH, Berlin	Framework agreement: AI for hospital billing review, compliance, AI governance (3 lots)	€121,000,000
07.12.2026	Stadt Brandis	Development of OpenCore modules for the PartheCloud	€625,600
08.12.2026	BWI GmbH, Bonn	Framework contract, notice "1961-JC-NoCodeDB" (software packages)	not published

Every row has the same flat fields:

{
  "noticeId": "779062-2026",
  "title": "Germany – Programming services of application software – Entwicklungsleistungen für OpenCore-Module der PartheCloud",
  "buyerName": "Stadt Brandis",
  "buyerCountry": "DEU",
  "buyerCity": "Brandis",
  "cpvMain": "72212000",
  "cpvCodes": ["72212000", "72262000", "72263000"],
  "formType": "competition",
  "procedureType": "open",
  "estimatedValue": 625600,
  "currency": "EUR",
  "publishedAt": "2026-11-09",
  "deadline": "2026-12-07T12:00:00+01:00",
  "lotsCount": 1,
  "url": "https://ted.europa.eu/en/notice/-/detail/779062-2026"
}

Two details that save you work:

deadline is the earliest lot deadline as an ISO timestamp, so sorting and "days left" are one line.
estimatedValue is summed across lots. It is null when the buyer did not publish a value (BWI above), which is common.

Choosing filters that actually match your business

CPV prefixes are the most useful filter. CPV is the EU's product vocabulary, and a prefix matches everything below it:

Prefix	Covers
`72`	IT services (consulting, development, support)
`48`	Software packages and information systems
`79`	Business services (consulting, marketing, translation)
`45`	Construction work
`90`	Cleaning, waste and environmental services
`33`	Medical equipment

Keywords are matched in full text in any language, so ["software", "Software", "logiciel"] widens the net across countries. Start broad, look at a week of results, then add minValueEur if small contracts are noise for you. Notices without a published value are kept, so you do not silently lose them.

Want to know who wins? Switch noticeTypes to ["result"]. Contract award notices show which buyer bought what, and often for how much: useful for competitor research and pricing.

Running it every morning

For a daily alert set publishedWithinDays to 2 (one day overlap as a safety net) and de-duplicate on noticeId:

import json, pathlib

seen_file = pathlib.Path("seen.json")
seen = set(json.loads(seen_file.read_text())) if seen_file.exists() else set()
new = [n for n in notices if n["noticeId"] not in seen]
seen_file.write_text(json.dumps(sorted(seen | {n["noticeId"] for n in new})))

for n in new:
    print(f'{n["deadline"][:10]}  {n["buyerName"]}: {n["title"][:90]}\n  {n["url"]}')

Schedule the script with cron or a GitHub Action, or use an Apify schedule and pipe the dataset into Slack or a sheet. If you prefer no-code, our free n8n sales-signal workflow does the same for German tenders and can take TED as a third branch.

Limits

TED lists notices above the EU thresholds (plus voluntary ones). Smaller national tenders are on national portals; for Germany there is our German Public Tenders actor.
Titles and summaries come in the notice language. The actor prefers your language (English by default) where the notice is multilingual.
This is a search tool, not procurement or legal advice. Always read the official notice before bidding.

What it costs

$0.002 per notice returned, and empty runs are free. The 50-notice daily run above costs at most $0.10; a typical "last two days, two countries, two CPV codes" run returns far fewer rows.

Try it

EU Tenders (TED) API on Apify
Agent users: the free find-public-tenders skill lets an AI agent run this search for you.

Question for bid managers: which filter do you rely on most, CPV codes or keywords, and how many false positives do you accept per day before an alert becomes noise?

How long do you get to bid on a German public tender? I checked 187 notices

Fast Data — Mon, 09 Nov 2026 17:45:42 +0000

If you sell to the public sector in Germany, the clock starts the moment a tender is published. So I wanted a simple number: how many days are there between publication and the bid deadline?

I took two daily snapshots (8 and 9 November 2026) of the public tender RSS feed on service.bund.de, the federal portal that also aggregates many state and municipal contracting bodies. After de-duplication that is 195 tenders published between 6 and 9 November. 187 of them state an offer deadline (Angebotsfrist) in the feed.

Disclosure: I built the German Public Tenders actor mentioned at the end. The analysis below uses only the free public RSS feed.

The result

Days to bid deadline	Tenders	Share
up to 14	16	9%
15–21	24	13%
22–30	88	47%
31–45	56	30%
over 45	3	2%

Median: 30 days. Shortest: 5 days. Longest: 64 days.
40 tenders (21%) give you three weeks or less. That is roughly one in five.

What this means in practice: if you check the portal once a month, you will miss most of the short ones entirely, and you will see the typical 30-day tender with only a week or two left. If public customers matter to you, the check has to be daily, or at least a few times a week.

Is construction faster than IT?

I grouped the titles with a crude keyword match (construction terms like Sanierung, Dach, Elektro, Los 3; IT terms like Software, Lizenz, Server). It is rough, so treat it as a hint, not a finding:

Group (by title keywords)	Tenders with deadline	Median days	≤ 21 days
Construction	77	30	16
Supplies	18	30	3
Services	13	30	4
IT / software	10	29.5	2
Other / unclear	69	29	15

The medians are almost identical. In this sample, the type of work does not predict the deadline; the individual contracting body does.

Where the tenders come from

German postal codes start with a zone digit, which gives a quick regional picture without parsing addresses:

Postal zone	Rough region	Tenders
5	Cologne, Bonn, Aachen, Koblenz, Trier	41
0	Saxony, East Thuringia, south Saxony-Anhalt	25
4	Ruhr area, Düsseldorf, Münsterland	24
3	Hanover, North Hesse, parts of Saxony-Anhalt	19
1	Berlin, Brandenburg, Mecklenburg-Vorpommern	12
9	Nuremberg, North Bavaria, most of Thuringia	11
2	Hamburg, Bremen, Schleswig-Holstein	10
6	Frankfurt, Saarland, Mannheim	8
7	Stuttgart, Karlsruhe	6
8	Munich, South Bavaria	4

Careful with this one. Several German states run their own procurement portals, so a low count here means "few of this region's tenders flow into this feed", not "few tenders in this region". If you only watch one portal, you only see part of the market.

Repeat it yourself

The feed is public and needs no key. This script fetches the newest 100 entries and computes the same distribution:

import re, statistics, email.utils, datetime as dt, html
import httpx

FEED = ("https://www.service.bund.de/Content/DE/Ausschreibungen/Suche/Formular.html"
        "?nn=4641482&type=0&resultsPerPage=100&sortOrder=dateOfIssue_dt+desc&jobsrss=true")

xml = httpx.get(FEED, timeout=60, headers={"User-Agent": "tender-deadline-study/1.0"}).text
days = []
for item in re.findall(r"<item>(.*?)</item>", xml, re.S):
    pub = re.search(r"<pubDate>(.*?)</pubDate>", item).group(1)
    desc = html.unescape(re.search(r"<description>(.*?)</description>", item, re.S).group(1))
    m = re.search(r"Angebotsfrist:\s*<strong>(\d\d\.\d\d\.\d{4})", desc)
    if not m:
        continue
    published = email.utils.parsedate_to_datetime(pub).date()
    deadline = dt.datetime.strptime(m.group(1), "%d.%m.%Y").date()
    days.append((deadline - published).days)

print(len(days), "tenders, median", statistics.median(days), "days")
print("3 weeks or less:", sum(d <= 21 for d in days))

Run it once a day and store the result, and after a month you have a much better sample than my four days.

Limits

Small sample. Four publication days, one portal. The shape (most deadlines around 30 days, a fat tail of short ones) is plausible, the exact percentages are not a statistic for all of Germany.
Feed dates. pubDate is when the notice entered the feed, which can be a day after the official publication.
Missing deadlines. 8 of 195 entries had no offer deadline in the feed, only an end of publication.
This is not legal or procurement advice. The official notice is what counts.

Try it

If you want the deadline, contracting authority, state, procedure type and CPV codes as clean JSON instead of parsing HTML in RSS descriptions, the German Public Tenders actor does that for $0.002 per tender. For EU-wide notices there is the EU Tenders (TED) API at the same price, and a ready-made n8n workflow that turns both into a daily Slack digest lives in our data-recipes repo.

Question for anyone who bids on public contracts: what is the shortest realistic time you need from "we found it" to a complete bid? I am trying to decide where to set the "urgent" threshold in the alert.

How to build a daily B2B sales-signal feed from public tenders and hiring data with n8n

Fast Data — Mon, 09 Nov 2026 12:45:43 +0000

Most "intent data" tools sell you a score without telling you where it comes from. But two of the strongest B2B buying signals are public and free to read:

A public body publishes a tender. It has a budget, a need and a deadline.
A company opens several jobs at once. It is growing, reorganising or starting a project, and it will buy tools and services for it.

This post is a ready-to-import n8n workflow that collects both every weekday morning, turns them into one feed with a simple score, and sends only the new signals to Slack, a Google Sheet and, if you want, Pipedrive or HubSpot.

Disclosure: I built the two Apify actors used here, German Public Tenders and Career Site Jobs API. The workflow is free in our data-recipes repo.

What the feed looks like

This is a real run from 8 November 2026 (keyword "Software", three target companies), passed through the workflow's own Code nodes:

Sales signals: 6 new (1 high, 3 medium, 2 low)
2 public tender(s), 4 job posting(s)

[high] Tender: Hochschule Zittau/Görlitz - Bereitstellung einer virtuellen Plattform ... - due 2026-11-13
    5 day(s) to end of publication
[medium] Tender: Stadt Regensburg - Einfuehrung und Nutzung eines Archivinformationssystems ... - due 2026-12-07
    30 day(s) to offer deadline
[medium] Hiring: Tibber - Pricing & Project Lead
    2 role(s) posted at Tibber in the last 7 day(s)
...and 2 more in the sheet

Every signal also lands as one row in a sheet: signalId, found_at, signalType, organisation, title, location, date, deadline, url, score, reason. Only organisations appear, never people or contact details.

The workflow

Weekdays 7:00 → Settings ─┬─ Get public tenders ─┐
                          └─ Get hiring signals ─┴─ Combine → Normalize & score
  → Read signal log → Keep new signals only ─┬─ Log new signals (Sheets)
                                             ├─ Build Slack digest → Post to Slack
                                             └─ High score only → Create Pipedrive activity (disabled)

All nodes are built in. The two data calls are plain HTTP Request nodes against Apify's synchronous endpoint, which runs the actor and returns its results in one step:

POST https://api.apify.com/v2/acts/fast_data_asap~german-public-tenders-bund/run-sync-get-dataset-items
Authorization: Bearer <your Apify token>   (Header Auth credential in n8n)

{"keywords": ["Software"], "states": [], "excludeKeywords": [], "lastDays": 2, "maxItems": 50, "includeDetails": true}

POST https://api.apify.com/v2/acts/fast_data_asap~career-site-jobs-api/run-sync-get-dataset-items

{"companies": ["teamtailor:tibber", "ashby:n8n", "greenhouse:celonis"], "postedWithinDays": 2, "maxJobsPerCompany": 25, "includeDescription": false}

The tender actor reads service.bund.de, the German federal portal that aggregates many federal, state and municipal publishers, and adds details such as contracting authority, place of performance, procedure type, CPV codes and the offer deadline. The jobs actor reads the public job-board APIs behind company career sites (Greenhouse, Lever, Ashby, Personio, Teamtailor, Workday and others), so there is no fragile HTML scraping.

All inputs live in one Settings node: keywords, optional German states, words to exclude, and your list of target companies. The lookback window is automatic: four days on Mondays to cover the weekend, two days otherwise. The extra day is a safety net if a run fails.

One schema, two simple scores

The Normalize & score Code node maps both sources to the same fields and applies two rules you can explain to any salesperson:

Tender: if the offer deadline (or, when none is published, the end of publication) is less than 21 days away, it is high. Someone has to make a bid/no-bid decision this week. Otherwise medium. Tenders whose deadline has already passed are dropped.
Hiring: three or more roles at the same company in the window is high. Two roles, or one leadership role (Head of, Director, VP), is medium. A single other role is low.

Signal	High	Medium	Low
Tender	deadline < 21 days away	deadline 21+ days away	– (expired tenders are dropped)
Hiring	3+ roles at one company	2 roles, or 1 leadership role	1 other role

Both thresholds are constants at the top of the node. In practice you will want to tune them: count only Sales or Engineering titles, or give extra weight to your core regions.

Deduplication with a Google Sheet

Instead of n8n's internal "seen before" memory, the workflow reads the signalId column of the sheet and drops anything that is already there. The ID is simply the type plus the source URL (tender:https://..., job:https://...). The advantage: the memory is visible. If a rep wants to see a signal again, they delete the row.

What the test showed

I ran each actor once with small limits (256 MB, a few results) on a Sunday:

Tenders: the keyword "Software" with a 2-day window returned 2 tenders (the search page had 100 results, 2 inside the window). One had a published offer deadline 30 days out; the other had no deadline, only an end of publication 5 days later, which is why the score falls back to that date. Weekdays bring more.
Jobs: Tibber had 13 open roles, n8n 48 and Celonis 233; with postedWithinDays: 7 and a cap of 1-2 jobs per company the run returned 4 postings. personio:personio returned 0, a reminder to check each company's career-site URL once.
Both calls finished in under 6 seconds.

What it costs

Both actors charge per result: $0.002 per tender and $0.002 per job posting on the Free and Starter plans. The test run returned 6 results, so $0.012. A realistic day with 10 tenders and 15 new jobs, each returned twice because of the overlap day, is about $0.10, or roughly $2 per month for 21 weekdays. You control the ceiling with maxTenders and maxJobsPerCompany.

Limits worth knowing

Tenders cover Germany via one portal. Not every contracting body publishes there, and some titles are truncated by the portal. For EU-wide notices, our EU Tenders (TED) API ($0.002 per notice) can be added as a third HTTP branch with the same schema mapping.
Hiring data is only as good as the career site. Custom career pages without a supported job board return nothing, and a re-posted job counts as new.
This is a lead feed, not procurement or legal advice. Read the official notice before you bid.

Setup in ten minutes

Import workflow.json from the repo folder into n8n.
Create a Header Auth credential (Authorization = Bearer YOUR_APIFY_TOKEN) and select it in both HTTP nodes.
Edit the Settings node.
Create a sheet with a tab Signals and the header row from the README, then connect Google Sheets and Slack.
Optionally enable the Pipedrive node, run once, and activate.

The workflow, the full README with the scoring table and the limits are in the data-recipes repo. Pull requests welcome.

Try it

Question for the sales and RevOps people here: which public signal has actually led to a meeting for you – tenders, hiring, funding news, or something else entirely? I would like to add the one that really works as the next branch.

How to build an AI accounts-payable check for German e-invoices with n8n

Fast Data — Mon, 09 Nov 2026 07:44:03 +0000

Germany is switching B2B invoicing to structured e-invoices. Since January 2025 every business must be able to receive them, and by 2028 most invoices between companies will be XRechnung XML or ZUGFeRD / Factur-X PDFs with embedded XML. For accounts payable that is good news: the IBAN, the supplier's VAT ID and the amounts are no longer pixels in a PDF, they are fields.

Fields can be checked automatically. This post is a ready-to-import n8n workflow that does a first-line check on every incoming e-invoice and gives it a traffic light, before anyone presses "pay". It is also a good building block for an AI finance agent: the agent gets clean, verified facts instead of guessing from a PDF.

Disclosure: I built the four Apify actors used here. The workflow is free in our data-recipes repo.

What it does

You drop an invoice file into a Google Drive folder (or POST its URL to a webhook). Then:

Parse the invoice: XRechnung (UBL or CII) or ZUGFeRD / Factur-X PDF to flat JSON with seller, buyer, IBAN, totals, VAT breakdown and plausibility warnings.
Check the IBAN: checksum, length, SEPA flag, and the bank behind the bank code from the official Bundesbank file.
Check the seller's VAT ID against the EU Commission's VIES service.
Screen the seller name against current warnings of BaFin, the German financial regulator (unauthorised firms, scam websites, identity clones).
A Code node turns the results into green / yellow / red with reasons, appends a row to a Google Sheet Eingangsrechnungen, and posts red invoices to Slack.

The workflow

All nodes are built in: Drive Trigger / Webhook → HTTP Request (parse) → three HTTP Requests (IBAN, VAT, BaFin) → Code (traffic light) → Google Sheets and Slack, with small Code nodes in between.

Every HTTP Request calls Apify's synchronous endpoint:

POST https://api.apify.com/v2/acts/fast_data_asap~xrechnung-zugferd-einvoice-parser/run-sync-get-dataset-items
Authorization: Bearer <your Apify token>   (Header Auth credential in n8n)

{ "fileUrls": ["https://.../invoice.xml"], "includeLineItems": false }

The three check calls look the same with their own input:

{ "ibans": ["DE79000000001234567890"], "includeBankInfo": true }
{ "vatNumbers": ["DE123456789"], "maxRetries": 3 }
{ "mode": "screen", "queries": ["Lieferant GmbH"], "minScore": 85, "maxMatchesPerQuery": 1 }

Two design choices matter in practice:

One call per actor per execution. A Code node collects the unique IBANs, VAT IDs and seller names of all invoices in the run, and the check nodes use Execute Once. Ten invoices from the same supplier cost one VAT check, not ten.
Checks never block the run. The check nodes use Always Output Data and On Error: Continue. If VIES is down for Italy, that invoice turns yellow with "VIES could not answer"; the rest go through.

The traffic-light rules

Red (do not pay before a human looked at it): the IBAN is invalid, VIES says the VAT ID is invalid, the VAT ID has an impossible format, or the seller name matches a BaFin warning with a score of 85 or more.

Yellow (could not verify): not a structured e-invoice, plausibility warnings from the parser (for example totals that do not add up), no IBAN on the invoice, bank code unknown, IBAN country differs from the seller country, VIES unavailable, VIES name differs from the invoice name, or a BaFin near-match.

Green: no automatic check found anything.

Each rule is a few lines in one Code node, so you can make it stricter or looser. One catch: German VAT IDs return no company name from VIES, so the name comparison only helps with suppliers from countries that share it.

What the real test showed

I ran the four actors on the two public test invoices from the parser's example input: KoSIT's official XRechnung test case 01.01a (UBL) and EN16931_Einfach.pdf from the Mustang project (a ZUGFeRD PDF).

The parser read both in 3 seconds: invoice 123456XX over 336.90 EUR at 7 % VAT, and invoice 471102 over 529.87 EUR with a 7 % and a 19 % VAT line. Zero plausibility warnings. The ZUGFeRD PDF has no IBAN at all in its XML.

Then the checks, and this is the interesting part:

The IBAN DE79 0000 0000 1234 5678 90 passed the checksum and length test, so a simple validator would call it valid. But its bank code is 00000000, and the actor answered "Bank code not found in Bundesbank list".
The VAT ID DE123456789, used by both test invoices, has a valid format. VIES said invalid.
BaFin: Lieferant GmbH was screened against 60 current warnings and measures, no match (best score 50). (33 seconds, it reads the live warning pages).

So both official test invoices end up red. That is the correct result: test files use placeholders that are formally perfect but do not exist. It is also the best argument for this workflow. A format check would have passed both invoices; the registry checks did not.

With real supplier invoices you will see mostly green, and yellow when a supplier leaves out the IBAN or VIES has a bad day.

What it costs

The actors charge per result, and failed items are free:

parse: $0.003 per invoice
IBAN: $0.0005
VAT ID: $0.001
BaFin screening: $0.01 per name

That is $0.0145 per invoice, about $1.45 for 100 invoices a month. BaFin is the largest part; screen long-standing suppliers once a month instead and a repeat invoice costs $0.0045.

What it does not do

This is a technical plausibility check, not tax or legal advice. It does not tell you whether an invoice satisfies § 14 UStG or whether you may deduct the input VAT.

The BaFin data covers roughly the last five weeks of warnings, because that is what BaFin publishes in machine-readable form. It is a check against current warnings, not a historical archive.

And it does not catch the most common invoice fraud: a real supplier's invoice with a changed IBAN that is perfectly valid, just not the supplier's. For that, add a supplier master-data tab and a rule "IBAN differs from the known IBAN". It is the first extension I would build.

Setup in ten minutes

Import workflow.json from the repo folder.
Create a Header Auth credential (Authorization / Bearer YOUR_APIFY_TOKEN) and select it in the four HTTP nodes.
Create a Drive folder, share it by link, and pick it in the trigger (or use the webhook with presigned URLs).
Connect Google Sheets (tab Eingangsrechnungen) and Slack.
Activate and drop the KoSIT test invoice into the folder: you should get a red row.

The workflow, the README with all rules and the sheet layout are in the data-recipes repo. If you would rather give these checks to Claude or Cursor directly, the same actors are available as MCP tools in the repo's Finance & Sales pack.

Try the actors directly: E-Invoice Parser · IBAN Validator · EU VAT Validator · BaFin Warnings

How do you check incoming invoices today: fully manual, rules in your accounting tool, or already with an agent?

This is a technical check, not tax or legal advice.

I counted every server in the official MCP Registry: 59,603 entries, and October alone added 16,282

Fast Data — Sun, 08 Nov 2026 17:46:56 +0000

The Model Context Protocol (MCP) is the standard that lets AI agents such as Claude, ChatGPT or Cursor call external tools. Its official registry at registry.modelcontextprotocol.io is where server authors publish their metadata, and it has a public, paginated API.

On 8 November 2026 I walked through the entire registry: 2,295 pages, 229,461 published versions. Here is what that says about where the agent ecosystem stands.

Disclosure: we publish one entry there ourselves (io.github.ichkifokkus/fast-data, Germany/EU business data tools via Apify). That is 1 of almost 60,000, so it does not move any of the numbers below.

The headline numbers

Metric	Value
Published versions (all)	229,461
Distinct servers (latest version)	59,603
… with a hosted remote endpoint	39,789 (67%)
… with an npm package	16,350
… with a PyPI package	5,280
… with an MCP bundle (`mcpb`)	2,250
… with a container image (OCI)	1,713
Names under `io.github.*`	34,156 (57%)

A server can have both a remote endpoint and packages, so the package rows overlap.

Growth: first publication per month

I took the earliest publishedAt of each server name as its "first seen" date:

Month	New servers
Sep 2025	456
Dec 2025	276
Mar 2026	1,938
May 2026	3,022
Jul 2026	5,072
Aug 2026	6,518
Sep 2026	11,849
Oct 2026	16,282
Nov 2026 (1–8)	5,728

October added more than five times as many new servers as May. The first eight days of November are already above the whole of July. The curve has not flattened.

Two caveats: the registry launched in preview in September 2025, so the early months partly reflect adoption of the registry itself, not of MCP. And "first published" only counts servers that are still listed today; anything deleted in between is invisible.

Remote first

Two thirds of all servers advertise a hosted remote endpoint (streamable HTTP or SSE). Local packages are the minority: npm leads with 16,350, PyPI follows with 5,280, and Rust (cargo, 122) and .NET (nuget, 175) are rounding errors.

For anyone building tools for agents, this matters more than it looks. Remote servers need no install, work in browser-based clients and can authenticate with OAuth. The ecosystem has clearly voted for "add a URL" over "install a package".

What the servers are about

I searched the latest descriptions for a few business keywords (case-insensitive substring match, so "search" also counts "research", and one server can match several words):

Keyword	Servers mentioning it
search	7,277
email	1,211
google	1,059
payment	1,004
invoice	695
database	502
calendar	413
sales	397
crm	333
finance	298
europe	219
german / germany	195 / 71
shopify	180
e-commerce / ecommerce	73 / 48

Search and retrieval dominate by a wide margin. Payments and invoices are surprisingly strong: over 1,000 servers mention payments and almost 700 mention invoices. Agents that pay and bill are clearly a thing people are building for.

At the other end, regional business data is thin. Fewer than 200 descriptions mention "German", fewer than 250 mention "Europe", and e-commerce shows up in barely more than 100. Given how much of the economy runs on country-specific rules (tax IDs, e-invoicing formats, public tenders, company registers), that gap is where I expect a lot of the next wave of useful servers.

Repeat it yourself

The API is public and needs no key. This script walks all pages, keeps the latest version of each server and counts first appearances per month:

import collections, httpx

BASE = "https://registry.modelcontextprotocol.io/v0.1/servers"
client = httpx.Client(timeout=30)

first_seen, latest, cursor = {}, {}, None
while True:
    params = {"limit": 100}
    if cursor:
        params["cursor"] = cursor
    page = client.get(BASE, params=params).json()
    for item in page.get("servers", []):
        meta = (item.get("_meta") or {}).get("io.modelcontextprotocol.registry/official", {})
        name = item["server"]["name"]
        published = meta.get("publishedAt") or "9999"
        first_seen[name] = min(first_seen.get(name, "9999"), published)
        if meta.get("isLatest"):
            latest[name] = item["server"]
    cursor = (page.get("metadata") or {}).get("nextCursor")
    if not cursor:
        break

per_month = collections.Counter(v[:7] for v in first_seen.values())
print(len(latest), "servers")
for month in sorted(per_month):
    print(month, per_month[month])
print("with remote:", sum(1 for s in latest.values() if s.get("remotes")))

A full pass takes a few minutes. Please be gentle with the registry: one pass a day is plenty for trend tracking.

What I take from it

The agent tool layer is growing faster than anyone can curate. At more than 500 new servers a day, discovery and trust (who maintains this, is it alive, is it safe) become the real problem, not supply.
Remote is the default. If you build a tool for agents in 2026, ship a URL.
Generic is crowded, specific is open. Search, email and Google integrations are everywhere. Country-specific business data, compliance checks and e-commerce rules are not.

That last point is why we keep a small, curated catalog of agent tools for German and EU business data, re-checked weekly.

Data: official MCP Registry API, full pass on 8 November 2026. Keyword counts are simple substring matches on descriptions and only indicate rough topic size.

How to get German job listings from the Arbeitsagentur as JSON or CSV (Python and n8n)

Fast Data — Sun, 08 Nov 2026 12:44:54 +0000

The Bundesagentur für Arbeit (Federal Employment Agency) runs Germany's largest job board, the Jobsuche. Its search is also reachable as data, which makes it the best free starting point if you need German job listings for a job board, a market report, a recruiting dashboard or just a daily alert for yourself.

This guide shows how to get those listings filtered by keyword, city, radius and date, as JSON or as a CSV file, and how to turn that into a daily alert. All numbers below are from real runs on 8 November 2026.

Disclosure: I built the tool used below, the Job Search API on Apify. It calls the official public job APIs; you don't need an Arbeitsagentur account.

Step 1: one city, one role, last 7 days

curl -X POST "https://api.apify.com/v2/acts/fast_data_asap~job-search-api/run-sync-get-dataset-items?token=YOUR_APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "keywords": "Data Analyst",
    "location": "Hamburg",
    "radiusKm": 25,
    "postedWithinDays": 7,
    "sources": ["arbeitsagentur"],
    "maxJobsPerSource": 20
  }'

This took 6.3 seconds and returned 7 jobs published in the Hamburg area during the previous week. Each one is a flat row:

{
  "title": "Data Analyst (m/w/d)",
  "company": "fabplus GmbH",
  "location": "21129, Hamburg, Germany",
  "remote": false,
  "employmentType": "full-time",
  "postedAt": "2026-11-03T00:00:00+00:00",
  "url": "https://www.arbeitsagentur.de/jobsuche/jobdetail/…",
  "source": "arbeitsagentur",
  "sourceJobId": "…",
  "tags": [],
  "salaryMin": null
}

Two things stood out in those 7 rows:

Two of the seven were the same client job, advertised by service providers. "Data Analyst (d/f/m) for AIRBUS" and "Data Analyst (d/m/w) für AIRBUS" were posted by two different companies. If you count jobs per employer, you need to account for ads that name the actual client only in the title.
Keyword matching is broader than the title. The search also returned a "Client Partner Banking" and a "Senior Business Analyst" role, presumably because the agency's own search matches tags and descriptions. If you need strict title matches, filter afterwards (see step 3).

Step 2: all of Germany, as CSV

Leave location empty to search the whole country. Add &format=csv to the endpoint and you get a CSV file instead of JSON, ready for Excel or Google Sheets:

curl -X POST "https://api.apify.com/v2/acts/fast_data_asap~job-search-api/run-sync-get-dataset-items?token=YOUR_APIFY_TOKEN&format=csv" \
  -H "Content-Type: application/json" \
  -d '{"keywords": "Python", "location": "", "postedWithinDays": 7, "sources": ["arbeitsagentur"], "maxJobsPerSource": 50}' \
  -o python-jobs.csv

My run hit the limit of 50 jobs in 7.5 seconds, so the real number of new Python listings that week is higher. Raise maxJobsPerSource for a complete pull. A few facts from those 50 rows:

Metric	Value
Marked as remote or home office	6 of 50
Full-time	48 of 50
With a salary figure	0 of 50
Most frequent cities	Berlin 5, Hamburg 4, Rostock 4, Bremen 3, Kassel 3

The salary row is the real gotcha: the Arbeitsagentur feed does not include salary data, so salaryMin and salaryMax stay empty for this source. If salary matters for your use case, add the arbeitnow, remoteok or himalayas sources, which sometimes include it, or read it from the description text with includeDescription: true.

Step 3: clean it up in Python

import httpx, pandas as pd

ENDPOINT = (
    "https://api.apify.com/v2/acts/"
    "fast_data_asap~job-search-api/run-sync-get-dataset-items"
)

def german_jobs(keywords, location="", days=7, limit=200, token="YOUR_APIFY_TOKEN"):
    r = httpx.post(
        ENDPOINT,
        params={"token": token},
        json={
            "keywords": keywords,
            "location": location,
            "radiusKm": 25,
            "postedWithinDays": days,
            "sources": ["arbeitsagentur"],
            "maxJobsPerSource": limit,
        },
        timeout=300,
    )
    r.raise_for_status()
    return pd.DataFrame(r.json())

df = german_jobs("Data Analyst", "Hamburg")

# strict title match: the agency search is broader than the title
df = df[df["title"].str.contains("data analyst", case=False)]

# drop the same job advertised by several service providers
df["title_key"] = df["title"].str.lower().str.replace(r"\(.*?\)", "", regex=True).str.strip()
df = df.drop_duplicates(subset=["title_key", "location"])

print(df[["title", "company", "location", "postedAt", "url"]])

On the Hamburg example the title filter leaves 4 Data Analyst jobs instead of 7. Two of those are still the same Airbus role (one ad says "for", the other "für"), so for serious counting add a client-name rule or a fuzzy match on top.

Step 4: a daily job alert in n8n

Schedule Trigger: every weekday at 07:00.
HTTP Request node: POST the input from step 1 to the endpoint, with postedWithinDays: 1 and your Apify token as a Header Auth credential (Authorization: Bearer …).
Code node: the strict title filter and duplicate removal from step 3 (a few lines of JavaScript).
IF node: stop when there are no rows.
Gmail, Slack or Telegram node: send one message listing title, company and link.

Swap step 5 for a Google Sheets append and you have a growing log of every matching job, which after a few weeks shows you which companies hire most in your field and city.

Other filters worth knowing

remoteOnly: true keeps only remote or home-office jobs.
filterByLocation: true drops jobs whose location text does not contain your city, useful when the radius pulls in too much.
companies: add careers-page URLs on Greenhouse, Lever, Ashby or SmartRecruiters to watch specific employers in the same run.
sources: combine the Arbeitsagentur with Arbeitnow, Remote OK and Himalayas for remote roles.

Cost

The actor charges $2.50 per 1,000 jobs returned. The 57 jobs in this article cost about 14 cents at that rate. A daily alert that returns 10–20 new jobs costs a few cents per month.

Data: Bundesagentur für Arbeit Jobsuche, queried 8 November 2026. Company names are as published in the job ads.