Reaching the accounting and Pro Account records inside Pennylane

Two different systems sit behind a Pennylane login, and any integration has to respect the seam between them. One is a payment account: a French IBAN, a Mastercard programme and SEPA transfers, operated for Pennylane by a regulated banking partner. The other is the accounting and billing engine that the company actually lives in day to day — supplier invoices, customer quotes and invoices, categorized transactions, and the Factur-X documents the French e-invoicing reform now requires. The bank layer is reachable under PSD2. The accounting layer is not. Knowing which record lives where is most of the work, so this page maps it.

The app describes a single space for purchases, sales and a Pro Account that stays in sync with the books. For a third party that wants those records in its own stack — a lender, an ERP, a treasury tool — the question is never “does the data exist” but “which authorized route returns each piece, and how durable is it.”

Pennylane in brief

The bottom line: the high-value records most teams ask for are the invoices and the categorized ledger, and those are only reachable through the authenticated session, not through the bank feed. So for Pennylane we build around the app's own session and treat the regulated Pro Account feed as a clean, separate add-on when a client wants it.

What records sit behind the login

Each row below is a surface the app exposes to its own users. The granularity is what we have seen the client render; exact field names get pinned against a consenting account during the build.

Authorized ways to reach each layer

Up to four routes apply here. Which ones we run depends on whether you need the accounting objects, the regulated payment feed, or both.

Authorized interface integration

We map the OAuth-style token and session the Pennylane client uses after sign-in, then replay the same JSON calls the mobile and web apps make, against an account the client controls and consents to. This is the route that returns the full object graph: invoices, quotes, categorized entries, the Factur-X stream, the cash-flow views. Effort is moderate. It tracks the front end, so we re-validate when the app ships changes. Access is arranged with you at onboarding — there is nothing to stage before we begin.

Regulated AIS consent (PSD2)

The Pro Account is a payment account, so a licensed AISP can read its balances and transactions under strong-customer-authentication consent through the dedicated open-banking interface. This route is durable and regulator-backed. It is also scoped: it returns the bank layer only, never the invoices or accounting entries. We handle the consent flow and, where it is needed, the AISP of record.

User-consented session access

A lighter variant of the first route. The account holder authorizes us, and we operate the authenticated session to mirror exactly what they see. Useful where AIS scope is too narrow and a full capture is more than the client needs.

Native export

Pennylane produces accounting exports and Factur-X documents directly. Good for historical backfill in bulk; not a real-time channel.

So how would we actually build it. The invoices, quotes, categorized entries and the Factur-X stream are what most clients are after, and none of them live in the payment-account layer PSD2 returns — which is why the authorized session against a consenting account does the heavy lifting for Pennylane. We bring AIS in only where someone specifically wants the regulator-backed Pro Account feed at Swan, and native export earns its place when years of documents would otherwise be pulled one call at a time.

The session, and a sample pull

Illustrative only. The exact paths, field names and the token lifecycle are confirmed against a consenting account during the build, not guessed here. It shows the shape: a bearer session after SCA login, cursor paging, and the two error cases that matter.

import httpx

BASE = "https://app.pennylane.com"   # web / mobile client origin

def session(bearer):
    # The client drives an OAuth-style token issued after SCA sign-in.
    return httpx.Client(
        base_url=BASE,
        headers={"Authorization": f"Bearer {bearer}",
                 "Accept": "application/json"},
    )

def sales_invoices(c, since, page=1):
    r = c.get("/api/customer_invoices",
              params={"updated_after": since, "page": page, "per_page": 100})
    if r.status_code == 401:
        raise TokenExpired          # hand back to the SCA refresh flow
    if r.status_code == 429:
        wait(retry_after(r))        # respect the rate-limit header
        return sales_invoices(c, since, page)
    r.raise_for_status()
    body = r.json()
    for inv in body["invoices"]:
        yield {
            "id":      inv["id"],
            "number":  inv["invoice_number"],
            "client":  inv["customer"]["name"],
            "total":   inv["amount"],           # tax-inclusive
            "status":  inv["status"],           # draft / sent / paid / late
            "facturx": inv.get("einvoicing_status"),
        }
    if body.get("has_more"):
        yield from sales_invoices(c, since, page + 1)

The Pro Account transactions follow the same pattern on a separate path, except that under the AIS route they come from the open-banking interface and carry the consent reference rather than the app session.

What you get at the end

• An OpenAPI/Swagger spec for the normalized surface — invoices, Pro Account transactions, quotes, categorized entries, Factur-X status — with one stable schema across both routes.
• A protocol and auth-flow report: the SCA login, the token chain and refresh, paging and rate-limit behaviour, written up so your team can maintain it.
• Runnable source for the key endpoints in Python or Node.js, not snippets — the listing, document-fetch and transaction calls wired together.
• Automated tests against recorded fixtures, so a Pennylane front-end change shows up as a failing test rather than a silent gap.
• Interface documentation and data-retention guidance: what each field means, consent scope, and what to log.

Where teams put this to work

• A lender reads a consenting merchant's Pro Account transactions and cash-flow indicators to underwrite a credit line without a manual statement upload.
• An ERP keeps its accounts-receivable in step by syncing Pennylane sales invoices and credit notes as their status moves from sent to paid.
• A spend-management tool mirrors supplier invoices and their categorization, so approvals happen in one place and post back cleanly.

Consent and the rules that apply in France

Every route here rests on the account holder's own authorization — that is the dependable basis, and it is what we document and log. For the Pro Account specifically, the regulated path is PSD2 account-information access, supervised in France by the ACPR (Autorité de contrôle prudentiel et de résolution, part of the Banque de France); per Pennylane's help centre the account itself is operated by Swan, a payment institution under that same supervision. Consent is scoped, time-limited, and revocable, and we design the sync to the re-authentication window PSD2 imposes rather than letting it lapse unnoticed.

Two reforms are moving and we treat both as forward-looking, not as settled obligations. The French e-invoicing reform phases in over 2026 and 2027 — per the finance ministry's timeline, companies must be able to receive electronic invoices from September 2026, with smaller businesses obliged to issue them from September 2027 — and Pennylane describes itself as Factur-X and PDP certified ahead of it. At EU level, PSD3/PSR reached a provisional political agreement in late 2025 with texts expected to be finalized through 2026, and the Financial Data Access (FIDA) regulation, which would extend authorized access beyond payment accounts to broader financial data, is still in negotiation. Where FIDA lands could change how the accounting layer is reached; until it does, consent-based interface integration is the route, and we do not assert obligations that are not yet law. Personal data is handled under the GDPR, minimized to what the use case needs, with NDAs where a client requires them.

What we plan for on a Pennylane build

These are the things that decide whether the integration holds up, and they are ours to handle, not yours to clear.

• The seam between Swan's payment-account layer and Pennylane's own accounting objects: we key the records so a Pro Account transaction lines up with its categorized entry and any matched invoice, instead of arriving as two disconnected feeds.
• Factur-X is a hybrid file, not a PDF. We parse the embedded XML for the structured fields and track the lifecycle and e-reporting status, so downstream systems read data rather than re-keying a document.
• Pro Account availability and limits differ by subscription plan, so we scope the capture per plan type and confirm which surfaces a given account actually exposes before we promise them.
• When Pennylane changes its front end we re-capture against a consenting account and patch the mappings, so the normalized output your systems depend on stays steady through the change.

What it costs and how the build runs

Most Pennylane scopes we have looked at land inside one to two weeks. Source-code delivery starts at $300: you receive the runnable API source and its documentation, and you pay once the delivery is in your hands and working as described. The other model carries no build fee at all — we host the endpoints and bill you per call, so you start small and scale with usage. Either way the brief from you is short: the app name and what you want out of its records; access, consent and any compliance paperwork are arranged with you as part of the work. Send the specifics through our contact page and we will come back with the route and a scope.

Screens we worked from

Listing images, used to confirm which records the app surfaces. Select to enlarge.

What was checked

This mapping was built in June 2026 from the app's own Play Store and help-centre material and from primary regulatory sources, cross-checked against the French e-invoicing and EU open-finance frameworks. The package identifier com.pennylane and the company and firm counts cited come from the app's own listing and are reproduced as it states them, not independently audited.

• ACPR — payment institution and account information service provider authorisation
• economie.gouv.fr — the French electronic-invoicing reform
• European Commission — framework for financial data access (FIDA)
• Pennylane help centre — Pro Account FAQ

OpenBanking Studio · integration desk — mapped June 2026.

Other French finance and accounting apps

The same integration approach maps onto the apps a Pennylane user is likely to also run. Names are listed to show the ecosystem, not to rank it.

• Qonto — a business account with invoicing and bookkeeping; transaction and card data behind an authenticated account.
• Shine — a neo-bank for small businesses and the self-employed, holding account movements and bookkeeping records.
• Indy — accounting and a bank account aimed at BNC professionals, with bank sync and VAT handling.
• Tiime — receipt capture and bookkeeping with connectors to French online banks; now part of Agicap.
• Agicap — cash-flow management that pulls incoming and outgoing flows from connected accounts.
• Regate — finance and accounting automation for firms and their clients.
• EBP — long-established French accounting and invoicing software with cloud and licensed editions.
• Sellsy — sales, invoicing and CRM holding quotes, invoices and customer records.
• MyUnisoft — accounting software built for expert-comptable firms and their portfolios.
• iPaidThat — invoice collection and expense automation that aggregates documents and bank data.

Questions integrators ask about Pennylane

Which Pennylane records come through the PSD2 feed, and which need another route?

The PSD2 path returns the payment-account layer - balances and transactions on the Pro Account held at Swan. Supplier and sales invoices, quotes, categorized entries and the Factur-X documents sit above that layer, so those come from the authorized session route rather than from AIS.

Does Factur-X data arrive as structured fields or just a PDF?

We read the XML embedded in the hybrid Factur-X file, so you receive structured invoice fields plus the lifecycle and e-reporting status, not a flat PDF that someone has to re-key.

Who holds the funds behind the Pro Account, and does that change access?

Per Pennylane's help centre the Pro Account is operated by Swan, a payment institution supervised by the ACPR. For the regulated feed that means account-information consent against that payment account, which we arrange with you during onboarding.

How does the integration survive Pennylane changing its app?

When the front end changes we re-capture the traffic against a consenting account and patch the field mappings, so the normalized output your systems read stays stable.