When should you build a custom Pennylane connector?

Pennylane already has a broad integration ecosystem. The first step should therefore not be to build a custom connector if an existing integration covers your needs properly. Start by reviewing the integrations already available in Pennylane.

Custom development becomes relevant when your process goes beyond what the standard connector supports: additional fields, company-specific rules, internal application synchronization, multi-step processing, significant volumes, or a need to control errors precisely. The goal is to remove a real operational break, not to connect Pennylane simply because an API exists.

For example, a sale approved in a CRM or business application can trigger invoicing without another manual entry. In the other direction, a financial status available in Pennylane can flow back to the CRM, customer support, reporting, or an internal application so teams share a consistent view of the process.

What can you connect with the Pennylane API?

Pennylane APIs cover different financial and accounting building blocks. The exact scope must always be checked against the API version, account type, and permissions actually available. The Pennylane API documentation distinguishes integration paths according to role and use case.

Flows can cover invoices, quotes, subscriptions, customers, suppliers, products, supplier invoices, documents, journal entries, and certain financial data when the required operations are available in the API used. A project should not promise a specific object without checking the scope of the relevant account.

Invoices, quotes, and subscriptions

Customers, suppliers, and products

Supplier invoices and documents

Journal entries and accounting data

Bank transactions and financial data

Connect Pennylane to a CRM

A company can keep using HubSpot, Salesforce, Pipedrive, or a business CRM for commercial operations while using Pennylane for financial processes. A won opportunity can provide the customer, offer, products, amounts, dates, and internal reference required by the flow.

The connector then transforms the data according to the agreed rules before sending what actually belongs in Pennylane. Financial information can flow back to the CRM when the integration supports it. Sales or customer service teams then have the right information without becoming daily users of the accounting platform. This approach complements a CRM connected to the rest of the information system.

Connect Pennylane to an ERP or business application

In many companies, Pennylane should not become the system that owns operational rules. The ERP or business application already knows orders, files, services, stock, interventions, or projects. That application is therefore often the one that knows when an event can become billable.

The business application owns the activity; Pennylane owns the appropriate financial and accounting operations. This separation avoids rebuilding in Pennylane rules that are already managed elsewhere. It fits an API integration approach in which each system retains a clear role.

A useful connector must also transmit reconciliation references, retain matching identifiers, and handle cases where a document already exists. Moving fields is not enough if the relationship between order, customer, invoice, and payment becomes unreadable.

Connect a back office or SaaS platform to Pennylane

For a SaaS publisher or a company with its own back office, an order, activation, usage event, or completed service can trigger billing in the product. The useful data can then be sent automatically to Pennylane instead of being exported and manually reworked.

The connector can retain Pennylane identifiers in the business database so objects can be matched correctly in later exchanges. This discipline becomes important when volume makes manual imports or name-based matching too fragile.

Native integration, Make, Zapier, n8n, or a custom Pennylane connector: what should you choose?

An existing native integration is generally the best choice when it properly covers the process. Make or Zapier can fit when the flow remains simple, available actions are sufficient, and the consequences of a failure are easy to correct.

n8n provides more control when several steps, transformations, or systems need to be orchestrated. A custom connector becomes more relevant when the flow carries important business rules, significant volumes, several systems, complex matching logic, or demanding monitoring and recovery requirements.

The approaches can coexist. A dedicated backend can handle critical financial logic while n8n orchestrates notifications or peripheral tasks. Technology should be chosen according to process criticality, not stack preference.

How do you avoid duplicates and contradictory data with Pennylane?

A reliable integration starts by defining the system of record for each object. The CRM can own the commercial customer, the business application the order, and Pennylane certain accounting information. The architecture must state who can create, edit, or only read each piece of data.

Each synchronized object needs a stable matching mechanism. Relying only on a company name, email address, or product label generally creates ambiguity. The corresponding identifier should be retained in the source system when relevant.

The connector must be idempotent when the process requires it. Replaying a message after a timeout should not automatically create a second invoice or customer. Good architecture also helps avoid duplicates and contradictory versions.

How do you handle webhooks, errors, and synchronization?

A production integration must be designed to work when everything goes well, but especially when something fails. An API may temporarily stop responding, reject data, or apply a rate limit. A webhook may be received more than once or arrive while a dependent system is unavailable.

Depending on flow criticality, the connector may need logging, controlled retries, idempotency, queues, error checks, and replay mechanisms. A failed operation must not disappear silently. Teams need to understand what should have been sent, what was received, why it failed, and whether it can be replayed automatically.

Clear monitoring connects the technical error to the relevant business object: invoice, customer, supplier, order, or document. It complements the page about how to monitor errors and asynchronous processing.

How do you secure a Pennylane API integration?

Tokens, secrets, and possible OAuth credentials must never be placed in clear text in code or shared across environments without control. They must be stored in an appropriate mechanism, with access limited to the services that genuinely need it.

Development, testing, and production should be separated where the project allows it. Pennylane documents a sandbox environment for testing calls without directly using production account data. Permissions and authentication then depend on the integration path selected.

The principle of least privilege should guide the connector. Do not request a Pennylane password, send a secret by email, or place credentials in the repository. Security also covers logs, test data, recovery access, and revocation procedures.

Company API, Firm API, or OAuth: what should you choose?

Pennylane exposes several integration paths depending on context. A company connecting its own tools will mainly use the Company API scope when it covers the need. Accounting firms have a distinct API scope adapted to their client portfolio and data.

An integration intended for broader use or multiple companies may require OAuth and the arrangements provided by Pennylane for integrations. You should therefore determine who will use the connector, across how many accounts, and with which data before choosing authentication.

Using OAuth does not mean that Koragence is an official Pennylane partner. The positioning remains that of a provider building integrations around public APIs and the technical context actually validated.

How does Koragence build a Pennylane connector?

We start by mapping the systems involved, the exchanged objects, and the actions that genuinely need to be automated. For each important data item, we define its system of record and the creation, update, and matching rules.

01. Check what already exists

Before development, we check whether an existing Pennylane integration or automation tool properly covers the need. Custom development only makes sense when it provides a capability the standard does not handle correctly.

02. Test the flow in a suitable environment

Where the context allows, the integration is tested through the sandbox environment with data suited to the planned scenario. We check mappings, controls, edge cases, errors, and replay before opening the flow to production.

03. Build and monitor

The connector is built with the mechanisms required by its criticality: logs, consistency checks, retries, queues, alerts, or a recovery interface. The goal is not only to move data, but to understand and resume the flow when processing fails.

04. Deploy, document, and maintain

Deployment includes secrets, environments, release procedures, and the documentation needed for takeover. Maintenance can then cover changes to Pennylane, the CRM, ERP, or business application, as well as monitoring and incidents.

How much does a custom Pennylane connector cost?

Budget depends less on the number of API calls than on the complexity of the process to secure. Linking one simple object between two applications is very different from a bidirectional flow handling several entities, billing rules, errors, recovery, and a monitoring interface.

The main factors are the number of systems, synchronized objects, direction of exchanges, business rules, volumes, error handling, and expected monitoring level. Initial scoping distinguishes a simple connector from a genuine financial integration layer.

Budget should also account for taking over an existing connector, documentation, testing, access, and maintenance when these elements are needed. There is no meaningful range without reviewing the real flow.

Should Pennylane handle e-invoicing from a business application?

A business application or ERP can keep the operational process while Pennylane receives the data needed for invoicing when the technical scope allows it. The Company API V2 documents, among other things, certain electronic invoice imports in Factur-X format.

You must nevertheless distinguish the technical creation or transmission of an invoice from the regulatory obligations applicable to the company. The connector should respect Pennylane’s actual role in the chosen financial architecture without claiming to replace the entire regulatory framework by itself.

What a good Pennylane connector really prevents

A useful connector prevents a commercial or operational detail from being entered in the business application, entered again in Pennylane, and then copied into a spreadsheet to check that both systems tell the same story.

It also prevents an API error from disappearing in a log until a team discovers several days later that an invoice or document was never transmitted. A good integration leaves clear ownership for each data item, an exchange history, and an actionable procedure when processing fails.