Article
Can n8n and Pennylane Really Automate Invoice Matching?
n8n does not ship an official Pennylane integration, but several community-built nodes connect n8n workflows to Pennylane's REST API v2, letting you push invoice data, create supplier and customer invoices, and trigger alerts automatically. What none of these workflows do by default is agreement-level invoice matching: checking a bill against the contract, SOW, or rate card behind it, rather than just its own totals or a purchase order number.
What are n8n and Pennylane, and why connect them?
n8n is a fair-code licensed, node-based workflow automation tool that lets you wire together apps and APIs without writing a full application. Pennylane is a French financial and accounting platform used by roughly 120,000 small and medium companies, most of them through their accounting firms, and it reached unicorn status in February 2024.
Teams that already run Pennylane for bookkeeping and n8n for automation naturally ask the same question: can the two be wired together to catch AP work before it reaches a person? The honest answer is that they can move data and trigger alerts, but "invoice matching" in the strict sense, comparing what was billed to what was agreed, is a separate problem that the plumbing alone does not solve.
Is there an official n8n-Pennylane integration?
No. There is no first-party node maintained by n8n or Pennylane. What exists are community packages, published on npm under names like n8n-nodes-pennylane-antislash, that wrap Pennylane's Company API (v2) to create and read customers, supplier invoices, customer invoices, and bank transactions. The most detailed of these documents that Pennylane's API enforces a default limit of 5 requests per second, which any workflow built on it has to respect or handle with retries. Community nodes are useful, but they carry the maintenance risk of any third-party package: no support contract, and updates depend on one or two maintainers keeping pace with Pennylane's API changes.
How would you actually build an invoice-matching workflow with n8n and Pennylane?
A typical setup looks like this:
- A trigger fires when a new supplier invoice lands in Pennylane, an inbox, or a webhook from another tool.
- n8n pulls the invoice line items and the matching purchase order number, if one exists, from Pennylane or a connected spreadsheet.
- A code or comparison node checks whether the invoice total matches the PO total, and whether the vendor name and invoice number look right.
- If the numbers match, n8n marks the invoice for approval or posts a note back into Pennylane. If they don't, it sends a Slack or email alert to the AP reviewer.
That is a real, working pattern. AP teams and consultants have published exactly this kind of build for invoicing and payment-tracking workflows, as seen in community n8n and Pennylane workflow examples. It is also, by design, a two-way match: invoice against purchase order. It has no concept of a contract, statement of work, or rate card unless someone manually loads those terms into the workflow and keeps them current every time a rate changes or a scope is amended.
What can this DIY workflow catch, and what does it miss?
It catches the things a two-way match is built to catch: a total that doesn't tie to the PO, a missing PO number, an invoice from a vendor not in your system, or a duplicate invoice number. It does not catch a contractor billing at a rate above their signed rate card, a scope change that was never re-approved, or a time-and-materials invoice with more hours than the SOW ceiling allows. Those failures require reading the agreement itself, not just the PO line, which is the gap our guide to invoice matching software and our breakdown of how three-way matching works both cover in more depth.
The stakes for missing this are not abstract. The ACFE's 2024 Report to the Nations estimates that organizations lose a median 5% of annual revenue to occupational fraud each year, and billing schemes, where a vendor invoice doesn't match what was actually owed, are among the categories tracked. A workflow that only checks "does the total match the PO" will wave through an invoice that matches the PO perfectly but bills the wrong rate.
DIY workflow vs. invoice-matching software vs. agreement matching
| n8n + Pennylane workflow | Invoice-matching software (2-way/3-way) | Agreement-aware matching | |
|---|---|---|---|
| What it checks | Invoice vs. PO or invoice vs. itself | Invoice vs. PO, sometimes vs. receipt | Invoice vs. the whole agreement: contract, SOW, rate card |
| Catches rate-card violations | No, unless manually coded per vendor | Rarely, unless rates are re-entered as line items | Yes, matched against the stored rate card |
| Who maintains the rules | Whoever built the n8n workflow | The vendor, within its matching logic | The vendor, updated as agreements change |
| Ongoing effort | High: you own every node, credential, and edge case | Low to moderate | Low, once agreements are loaded |
| Support if the API changes | Community maintainer, if one is still active | Vendor support | Vendor support |
When does a custom n8n workflow stop making sense?
A hand-built workflow is a reasonable starting point when invoice volume is low and the rules are simple: one or two vendors, flat monthly retainers, no rate cards to track. As volume grows past roughly 200 invoices a month, the honest threshold where most automation approaches, DIY or purchased, start paying for the time invested, the maintenance burden of a custom workflow (broken nodes, API changes, someone leaving who understood the logic) tends to grow faster than the time it saves. That is also the point where many finance teams are deciding between absorbing the extra invoice volume into their current process with better tooling, or making their next AP hire. Neither is automatically wrong; the honest answer depends on how repeatable your invoices actually are.
What should you check before relying on a DIY invoice-matching workflow?
Before trusting an n8n and Pennylane workflow with real AP decisions, confirm three things: what happens when the API rate limit is hit mid-batch, who gets paged when a community node breaks after a Pennylane API update, and whether the workflow's "match" logic can see anything beyond the PO total. If the answer to that last question is no, the workflow is still worth having for data entry and reminders, but it should not be the last check before a bill gets paid.
FAQ
Does n8n have an official Pennylane integration?
No. n8n does not maintain a first-party Pennylane node. Several community-built nodes exist on npm that wrap Pennylane's Company API (v2) and support creating and reading invoices, customers, and transactions.
What does Pennylane's API rate limit allow?
Community n8n nodes for Pennylane document a default limit of 5 requests per second on Pennylane's API, which a workflow needs to handle with pacing or retries when processing invoices in bulk.
Can an n8n workflow catch overbilling or rate-card violations?
Not by default. A workflow built on n8n and Pennylane typically checks an invoice total against a purchase order, which is the same scope as a two-way or three-way match. Catching a rate charged above a signed rate card or hours over an SOW ceiling requires checking the invoice against the underlying agreement, not just the PO.
Is a DIY n8n workflow enough for a growing AP volume?
It depends on volume and complexity. Below roughly 200 invoices a month with simple, repeatable rules, a custom workflow can work fine. Above that, the maintenance cost of a hand-built integration, and the blind spots in PO-only matching, tend to outweigh the time it saves.
How many businesses use Pennylane?
Pennylane serves roughly 120,000 small and medium companies in France, most through their accounting firms, according to reporting on its February 2024 unicorn funding round.