I built a set of 3 production-ready n8n workflows that integrate with Pennylane, the leading accounting platform for French SMEs. The workflows automate the full invoicing lifecycle using the Pennylane API v2.
What’s included
WF1 — Auto Invoice from Webhook
Receives data from any CRM or app via webhook, creates or finds the customer in Pennylane, generates a customer invoice with line items and VAT, optionally sends it by email, and notifies your team via Slack and/or Gmail.
WF2 — Track Payments
Runs every 15 minutes, fetches all invoices, classifies them as paid, overdue, or upcoming, and sends a Slack notification when changes are detected.
WF3 — Overdue Reminder
Runs daily at 9 AM, identifies invoices overdue by 7+ days, and sends a detailed Slack reminder with direct links to the invoice PDFs.
Each workflow section is documented with colored Sticky Notes
Tested against the Pennylane API v2 sandbox — the repo documents every API quirk we found (wrong endpoint names, mandatory fields, filtering limitations, rate limits)
Credentials are cleaned from the JSON files — import, add your own creds, and go
Includes example payloads, CRM integration mappings (Pipedrive, Sellsy, Axonaut), and a troubleshooting guide
So the Slack notification is to send it directly to the customers or to the team to review them first? I mean, do you have a human-review or a validation steps in the flow to verify that all information is correct?
In the current design, Slack notifications go to the team — not to the customer. The customer-facing communication is handled separately by the PL Send Invoice Email node, which sends the invoice directly through Pennylane’s own email system (only when send_email: true is set in the payload).
Regarding human review: the workflow as published does not include a manual approval step before invoice creation. It’s designed as a fully automated pipeline, which fits use cases where the data coming from the CRM/webhook is already validated (e.g., a deal marked as “Won” in Pipedrive with confirmed amounts).
That said, adding a human-in-the-loop step is straightforward. You could:
Set draft: true in the Code Build Invoice Payload node (one-line change) — this creates the invoice as a draft in Pennylane instead of finalizing it
The Slack notification then serves as a prompt for someone to review and finalize the invoice manually in Pennylane
Or, for a more advanced setup, you could add a Slack interactive message with “Approve / Reject” buttons that triggers a second workflow to finalize or discard the draft
I kept the default to draft: false (auto-finalize) to keep the template simple, but draft: true is probably the safer starting point for most teams. I’ll add a note about this in the README.
The API learnings section in the repo was born out of frustration — most of these quirks aren’t wrong in the docs, they’re just not what you’d write instinctively. Glad it’s useful.
On rate limits: the 15-minute interval is intentional but not primarily about rate limits. Pennylane allows 4 req/s for most endpoints and 2 req/s for customer invoice endpoints. A single poll (one GET /customer_invoices call + client-side classification) is well within that budget.
The 15-minute interval is more about signal-to-noise ratio. Polling every minute would technically work, but you’d flood Slack with “no updates” silence or redundant notifications. 15 minutes felt like the right balance between responsiveness and not crying wolf. For teams that need tighter tracking (e.g., high invoice volume or cash-sensitive operations), you can safely drop it to 5 minutes without hitting any limits.
WF2 doesn’t include explicit rate limit handling (no retry-on-429 logic). If you’re running all 3 workflows on the same Pennylane token and hitting limits, the simplest fix is staggering the schedules (e.g., WF2 at :00/:15/:30/:45, WF3 at :05 daily) so they don’t overlap.
