ERPNext bank feeds with Plaid

Replacing CSV statement imports with ERPNext bank feeds from Plaid

If someone on your finance team downloads bank statements every week and loads them into ERPNext by hand, reconciliation will almost always trail the bank. The useful question for this section is whether a Plaid-based feed can pull bank transactions into ERPNext on a schedule, so that the team reconciles against records that already exist. A feed does not remove reconciliation. It replaces the manual step of getting transactions into the system, and the matching work in the bank reconciliation tool still needs an owner.

The setup depends on two things: site configuration keys that hold the Plaid credentials and environment for your site, and bank accounts linked through the Plaid flow and mapped to the correct ERPNext Bank Account and GL account. Each synced line lands as a Bank Transaction record, which is what the reconciliation tool matches against vouchers. Decide early which accounts will be linked, who approves the link, and how duplicates from an overlapping CSV import will be prevented during the cutover month. Confirm the exact configuration key names, the supported ERPNext version and the Plaid product in the ERPNext and Plaid documentation for your target release before scoping.

Country and institution coverage is the constraint that most often changes the plan. Plaid's coverage varies by country and by bank, and an account at an unsupported institution will not sync no matter how the site is configured. Ask your bank list in writing, check it against Plaid's current coverage, and keep a documented fallback for every account that will not connect, such as the existing CSV import with the Data Import tool or a bank file format your bank provides. Treat the fallback as part of the design, so that a missing feed does not leave reconciliation behind.

What you need before linking a bank account

Bank feeds depend on decisions made outside ERPNext as much as inside it. The items below cover the ERPNext and Frappe version, the Plaid account, the bank accounts, the people who own reconciliation and the public address Plaid needs. Confirm each one before scoping the work, because gaps here delay the build more than any configuration step.

Supported ERPNext and Frappe version

Check that your site runs a Frappe version that is still in support before adding a new integration. Version 14 reached end of life on January 31, 2026, so sites on it need an upgrade plan first. Version 15 is planned for support until the end of 2027 and version 16 until the end of 2029. Confirm the current dates on the Frappe supported versions page, since that page is the reference.

Plaid developer account and product approval

Create a Plaid developer account and confirm that it is approved for the products and institutions you need. Plaid access depends on its own approval process, which can differ by product and country. Ask Plaid which institutions your bank list covers and whether your use case needs production access before the build starts.

Bank account for each company and currency

List every bank account that will feed ERPNext, grouped by ERPNext company and by currency. Each linked account should map to a single Bank Account record in the matching company. Mixed currencies and shared accounts across companies are common causes of reconciliation errors, so settle these mappings in writing before linking anything.

Named finance owner for reconciliation

Assign one person in finance to own the feed, approve reconciliation matches and review unmatched Bank Transactions each period. Synced data still needs human review, especially for transfers, fees and partial payments. Without a named owner, feeds often run correctly on the technical side while open items accumulate.

HTTPS and a public callback address

Confirm that the ERPNext site is served over HTTPS with a valid certificate and a public address that Plaid can reach if your setup uses webhooks. Internal-only sites need a reverse proxy or a different sync approach. Check your firewall rules, certificate chain and redirect behavior before configuring the integration keys.

Fallback path for unsupported banks

Decide now how transactions from banks that Plaid does not cover will arrive. The usual fallback is the Data Import tool with CSV or Excel statements, which should use the same Bank Account records. Import in batches of a few thousand records at a time, as the documentation advises, and keep the file format consistent so matching rules still apply.

Deciding whether a Plaid feed fits your bank footprint

Start by confirming that each bank you pay or receive money through appears on Plaid's current institution list for your country. Coverage is granted per institution and per country, so a large bank in one market does not imply coverage in another. Confirm the specific data products you need, such as transaction history, balances or account identity, because an institution can support some products and not others. Check whether the bank requires its own agreement or onboarding step before data flows, since that can add lead time that sits outside your ERPNext configuration. Also ask how often connections need re-authentication, because an expired consent stops the feed until a user signs in again and that interruption affects your reconciliation calendar.

Institution list: Look up each bank by country on Plaid's published list, not on a third-party summary.
Product availability: Confirm transactions and balances separately for each institution.
Bank-specific agreements: Ask whether the institution needs its own approval before connection.
Re-authentication cycle: Find out how often users must reconnect and who receives the alert.
Account types: Verify that business current and savings accounts are supported, not only personal ones.

Confirm every item against Plaid's current published coverage list, because this page does not state coverage limits.

Configuring Plaid credentials and linking bank accounts in sequence

This sequence moves Plaid from a sandbox test to live bank synchronization in ERPNext, with credentials kept out of version control, one ERPNext Bank Account mapped to each linked institution, and a checked first sync before any reconciliation work begins. Each step ends with a verification the finance team can sign off.

Confirm Plaid and ERPNext versions before configuring
Before any change, the implementation lead records the ERPNext and Frappe Framework version running on the target site and confirms it is on a version listed as supported on the Frappe supported versions page. Confirm with Plaid which API version, environment names and Link product configuration apply to your account, and confirm with the ERPNext release notes that the bank feed integration in your version exposes the same settings described in the vendor documentation. Record both confirmations in the change ticket. Done when the version matrix is signed off by the platform owner and the finance lead.
Store Plaid credentials as site configuration keys
The platform engineer adds the Plaid client ID and secret to the site configuration file for the target site, using the key names documented for your ERPNext version, rather than placing them in a fixture, custom app or Git repository. Secrets are injected from your existing secrets manager during deployment where possible, and file permissions on the bench directory restrict read access to the service account. Confirm the repository contains no credential strings by running a secret scanner over the committed code. Done when the site starts, the keys resolve from configuration and the scan returns no matches.
Select the sandbox environment and test the connection
Before any production credential is used, the finance systems administrator configures the Plaid environment setting to sandbox on a non-production site, which should be a copy of the production data model. The administrator then triggers the connection test from the bank feed settings page and reviews the application log for authentication errors. Sandbox institutions and test credentials come from Plaid's sandbox documentation, so no real bank data is exposed at this stage. Done when the connection test succeeds and the log shows no authentication failures.
Map ERPNext Bank Account records to each institution
The accountant creates or reviews one ERPNext Bank Account record for each real bank account the company holds, linking each to its ledger account in the chart of accounts and setting the account currency. Each record is then matched to the institution and account identifier that Plaid will return, so that incoming transactions land in the correct ledger. Two accounts at the same bank must never share one ERPNext record. Done when a list of planned mappings is reviewed line by line against the bank statements, with currency and ledger account confirmed for each.
Run the Plaid link flow for each account as an authorized user
A user holding the bank feed permission, not a shared or generic administrator, opens the bank connection screen and completes the Plaid Link flow for each institution, signing in with the bank's own credentials inside Plaid's interface. The user selects the account to link and confirms the mapping to the ERPNext Bank Account created in the previous step. Keep a record of who linked each account and when, because the link is tied to that user's authority to access the bank. Done when every planned account shows as linked with the correct mapping and the audit trail names the authorizing user.
Run an initial sync over a short date range
Set the initial sync window to a short, recent period, so the first import is small enough to check by hand, then trigger the sync for one account at a time. Look for newly created Bank Transaction records in ERPNext and check that the bank account, currency, posting date, amount and description match the source. If duplicate or missing records appear, stop, review the sync log and do not widen the window until the cause is known. Done when the first window imports without duplicates and the log records a completed run for each account.
Reconcile a sample of transactions against the bank portal
The accountant selects ten Bank Transaction records across the linked accounts, including at least one credit, one debit and one transaction in a non-base currency where the account uses one, and compares each one with the entry shown in the bank's own portal. The accountant confirms the amount, value date, currency and counterparty text and records any mismatches in the change ticket. Only after the sample matches should the finance team extend the sync window and begin using the feed for reconciliation. Done when all ten sampled records match the bank portal and the sign-off is recorded.

Mapping Plaid transaction fields to ERPNext Bank Transaction fields

This table compares each Plaid transaction and account field with the ERPNext Bank Transaction or Bank Account field it should populate, the transformation required and who signs it off. Read it as a build specification: confirm every field name against the Plaid schema and the ERPNext DocType for your chosen version before writing any mapping code. The main takeaway is that sign convention, date choice and the duplicate key cause most reconciliation problems if they are agreed late.

Plaid field	ERPNext Bank Transaction field	Transformation needed	Sign-off owner
account_id on the transaction, matched to the Plaid account	Bank Account (linked to the GL bank account)	Map each Plaid account to exactly one ERPNext Bank Account; reject transactions from unmapped accounts	Finance controller
amount	Deposit or Withdrawal	Plaid reports outflows as positive numbers, so confirm the sign convention in the schema and split positive and negative values into the correct column	Accounting lead
iso_currency_code	Currency	Check it matches the Bank Account currency; route mismatches to an exception queue instead of posting	Finance controller
date	Date (transaction date)	Use the transaction date as the reporting date only if your bank cut-off policy agrees with it	Accounting lead
authorized_date or posted date	Date or posting date used in reconciliation	Decide one date rule for matching bank statements and document why; do not mix dates across months	Month-end close owner
name or merchant_name	Description	Concatenate and truncate to the field length in your version; keep the original text for audit	Bank reconciliation specialist
payment_meta.reference_number	Reference Number	Copy when present; many banks omit it, so reconciliation must not depend on it	Bank reconciliation specialist
pending flag	Status or exclusion rule	Import pending items only if your policy allows; exclude them from reconciliation until they post	Controller
transaction_id	Transaction ID or unique key used for deduplication	Store as the idempotency key so repeated syncs and webhook retries do not create duplicate Bank Transactions	Integration engineer

How synced Bank Transactions feed reconciliation

Synced bank data arrives in ERPNext as Bank Transaction records that stay unreconciled until someone or some rule matches them. The Bank Reconciliation tool then pairs each bank line with payments, invoices or journal entries already in the books. Nothing is posted to the ledger just because a transaction appeared in the feed, so the team's first design decision is which matches may be accepted automatically and which must be reviewed by a person. Start by writing those rules down: exact amount with a matching reference, a tolerance for bank fees or currency rounding, and how partial payments against one invoice or one bank line for several invoices should be handled. Each rule should name the account, the party type and the approver for exceptions.

Pending transactions need an explicit policy because banks can change or withdraw them before they settle. Decide whether pending items are imported at all, whether the team waits for settled status before matching, and what happens when an already matched line later changes amount or disappears from the feed. Reconciliation history is part of the audit trail, so unmatching, correcting and re-matching should be restricted to named roles and logged. Confirm with your bank data provider and Plaid's documentation how pending and modified transactions are represented in the payload your site receives, since that determines what your team has to handle by hand.

If CSV statements will still be imported for accounts or periods Plaid does not cover, duplicate detection becomes a design decision rather than a cleanup task. The same bank line can arrive through the feed and through a file, and a duplicate Bank Transaction can match an invoice twice or inflate reconciled totals. Choose one source of truth per bank account, define how overlapping date ranges are handled, and test these rules on a copy of real data before go-live, including a month with known fees, a partial payment, a reversed payment and a pending item that later settles. Record the results so the reconciliation approach can be explained to auditors.

Securing bank credentials and transaction data

Plaid bank feeds give ERPNext a live path to account and transaction data, so the credentials, the people allowed to link accounts and the stored transaction details all need deliberate controls. The cards below cover each control and what to check in your own site before go-live. None of these steps on its own makes the setup compliant with any framework, so confirm requirements with your auditor and your Plaid contract.

Keep Plaid secrets out of code

Store the Plaid client ID, secret and environment values in site configuration or a secrets manager that your platform team controls, never in custom scripts, fixtures or the Git repository that holds your custom app. Check that exported customizations and backups do not carry these values in plain text, and that developer sandboxes use separate Plaid credentials from production. Ask Plaid which environment and key rotation options your account supports before you wire the keys into the site.

Limit who can link accounts

Linking and unlinking a bank account is a high-impact action, so restrict it to a small group of accountants or finance administrators through ERPNext roles and role permissions. Review which users hold roles that can edit Bank Account and Bank Transaction records, and remove broad System Manager access from routine users. Test the restriction with a non-admin account before the feed goes live.

Log link and sync events

Record who linked or unlinked each bank account, when each sync ran and how many transactions it imported or failed to import. Use the Version history on the relevant documents and the Error Log for failed jobs, and send these records to the log store your security team already monitors. Review the log at a set interval so a stray link or failing sync is noticed before month-end reconciliation.

Verify webhook signatures

The webhook endpoint that receives Plaid notifications should accept only requests that carry a valid Plaid signature. Verify the signature as Plaid documents, reject requests that fail the check or arrive outside an accepted time window, and keep the verification key in the same secrets store as your other Plaid values. Test rejection with a deliberately altered payload in a staging site, and confirm the endpoint is reachable only over TLS.

Minimize transaction remarks

Bank Transaction records keep the description text supplied by the bank, which can include account numbers, names or personal details. Decide which fields your reconciliation actually needs, and avoid copying full bank descriptions into remarks, comments or notification emails. Review a sample of synced records and any custom print formats or reports that display them, and set a retention period for synced transaction data that matches your own policy.

Plan rotation and revocation

When a staff member who linked accounts changes roles or leaves, the access tokens and user permissions tied to that work need review. Write a procedure that revokes Plaid access for affected items, rotates the client secret when a copy may have been exposed, and removes or reassigns ERPNext roles the same day. Rehearse this procedure once in staging so the steps and owners are known before an incident.

Keeping a fallback for banks Plaid does not cover

Plan the fallback before go-live, because some banks, countries and account types will not be available through a Plaid feed. For each account in scope, the team should record whether the feed is active, which statement source covers it, and who owns that decision. The fallback is part of the design, not an afterthought. Confirm for the ERPNext version in use whether the existing bank statement import tool can load the statement formats your banks provide, and whether it creates Bank Transaction records in the same way the feed does. Do not assume this from the version number alone. Test it against a real statement from each bank you expect to rely on, since column layouts, date formats and decimal separators vary by institution and by country.

Set one rule and enforce it operationally: a given account and period must be loaded from one source only. If the feed has already created Bank Transactions for March, a statement file covering March must not be imported on top of them, or every line will appear twice and reconciliation will show false differences or false matches. Record the source and the covered date range for each load in a simple log, and check for overlapping ranges before any manual import. Agree in writing who approves a switch between feed and file for an account, typically the finance controller with IT sign-off, and what evidence they need: the last reconciled date, the first and last transaction dates in each source, and the closing balance check.

Test the fallback with the same reconciliation checks you use for the feed. That means comparing closing balances against the bank statement, confirming that no transaction is duplicated across sources, and verifying that matched entries reconcile to the correct ledger accounts. Run this test on a non-production site with representative data from each fallback bank before relying on it in a close. Document the steps so that someone other than the implementer can run them during a month-end when the feed is down.

Common failures when syncing bank feeds into ERPNext

This table pairs each symptom seen after linking a bank through Plaid with its likely cause and a check to run. Treat each fix as a diagnostic step to confirm in your own site, not a guaranteed resolution. Work through the rows in order, because account mapping and sync scheduling are the first places to look.

Symptom	Likely cause	Check to run
Link succeeds but no Bank Transactions arrive	The linked Plaid account is not mapped to an ERPNext Bank Account, or the sync job is not scheduled	Confirm the Plaid account is mapped to the correct Bank Account record, then check that the scheduled sync runs and logs an attempt
Duplicate transactions after re-linking the bank	Re-linking created a new feed without a check on the bank's unique transaction identifier	Search Bank Transactions for repeated transaction IDs and dates before deleting anything, then confirm the dedupe behavior on your version
Amounts have the wrong sign or currency	Debit and credit direction from the feed is mapped inconsistently, or the account currency differs from the bank's reporting currency	Compare three transactions against the bank statement for sign and currency, and check the Bank Account currency setting
Transactions disappear after the bank requires re-authentication	The Plaid item entered an error state and syncing stopped until the user completed the update flow	Check the item status in your Plaid dashboard, complete the re-authentication in Link update mode, and confirm the sync resumes from the last stored date
Sync fails after an ERPNext or Frappe upgrade	The bank integration app or its configuration keys changed between versions, or a custom script depends on an old hook	Review the release notes for your target version, check the site configuration keys, and run the sync in a staging copy before production
Reconciliation fails because posted dates differ from pending dates	The feed records a pending transaction with one date and later posts it with another, so the amount matches but the date does not	Set a reconciliation date tolerance you can justify, and confirm whether your bank supplies pending items before reconciling against statements

Questions finance and IT teams ask before a Plaid bank feed

What drives the cost and effort of a Plaid bank feed for ERPNext?

The main drivers are the number of bank accounts, the number of countries and institutions involved, how much custom mapping the chart of accounts needs, how much testing the reconciliation rules require, and how the fallback path for unsupported banks is designed. Each additional country or institution adds coverage checks, credential setup and test cases. One-time work includes configuration, linking accounts, mapping and testing. Recurring costs come from re-authentication handling, upgrades and monitoring, plus any Plaid usage charges, which you should confirm directly with Plaid. Ask for a quote that lists each bank account, country, mapping rule and fallback as a separate line so you can see what changes the price.

Can our own team set up a Plaid bank feed in ERPNext?

Yes, a team can do this itself if it has an ERPNext developer who can manage site configuration and a finance owner who can judge whether synced Bank Transactions reconcile correctly. The developer needs to be comfortable with site configuration keys, background jobs and how Bank Transactions are matched. The finance owner needs to review samples before go-live. Two points need vendor confirmation before you start: whether your Plaid account and access level cover the banks you use, and which institutions are supported in your countries. Plaid's current coverage list and your Plaid account terms are the sources to check, not this page.

How long does a Plaid bank feed take to implement?

The duration depends on scope and on approvals, not on a fixed rule. Timing is usually set by how many accounts are involved, how quickly bank access and Plaid credentials are approved, how many reconciliation samples need review, and whether the fallback path must be built before go-live. Approval steps owned by your bank, your Plaid account or your internal security review can take longer than the configuration itself. Ask for a written schedule in the quote that shows each approval as a dependency with an owner, and that lists the review rounds the finance team must complete.

What do we need to provide for a Plaid bank feed engagement?

You will need to provide four things. First, bank access approvals for each account, including authority to connect them through Plaid. Second, a sandbox or test environment and test accounts so mapping and reconciliation can be checked without touching live money. Third, reconciliation samples from your current CSV process, covering typical transactions, fees, transfers and corrections, so the rules can be tested against real patterns. Fourth, a named reviewer on your finance side who can approve mapping decisions and sign off test results. Without a named reviewer, decisions tend to stall during testing.

Will Plaid support our bank, and can that be guaranteed?

No, coverage cannot be guaranteed from this page, and it can change over time. Whether a specific bank is supported depends on the institution, the country and Plaid's current coverage list at the time you check. Confirm your exact banks, account types and countries against Plaid's current list before you commit to a design. Plan the fallback for any bank that is not supported, such as a structured CSV or statement import, so an unsupported institution does not stop reconciliation. Ask your implementation partner to document which accounts are covered and which use the fallback.

How is a Plaid bank feed maintained after go-live?

After go-live, the feed needs routine attention in three areas. Re-authentication is needed when a bank requires users to confirm access again, so you need a process for who receives the alert and how quickly it is handled. Upgrades matter because ERPNext and its apps change across major and minor releases, and the sync configuration must be tested after each upgrade. Monitoring should check that scheduled sync jobs run, that new Bank Transactions appear, and that reconciliation match rates do not drop unexpectedly. Ask for a written runbook covering these checks, the alert owner and the upgrade test steps. Ongoing support and continuous checks are available as a retainer if you do not want to own them internally.

How DeployOpen scopes and delivers bank feed integrations

DeployOpen plans, implements, customizes, integrates, hardens and documents self-hosted open-source platforms inside your own infrastructure, including ERPNext bank feeds with Plaid. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.

How we scope

Confirm which banks and countries you need, and whether Plaid coverage exists for each one before design begins.
Map each bank account to its ERPNext company, currency and Bank Account record, with owners named.
Agree in writing what the Plaid integration covers, which fallback applies to unsupported banks and what is out of scope.
Ask for the scope to state how Plaid credentials and the site configuration keys will be stored and rotated.

How we build

Set up the Plaid connection on a non-production ERPNext site first, using sandbox-style test accounts before live linking.
Configure Bank Account links and sync settings, then check that synced Bank Transactions land in the expected accounts.
Test reconciliation with real statement samples from each bank, comparing matched and unmatched entries against the bank's own records.
Build any fallback import template and document the CSV steps used for banks outside Plaid coverage.

How we hand over

Deliver a written runbook covering linking new accounts, handling expired bank connections and rotating credentials.
Document the configuration keys, the reconciliation workflow and the exact checks an accountant should perform at month end.
Walk your finance and IT staff through the setup and the failure cases, and record who owns each step after go-live.

How we support

Ongoing support, upgrades and testing are available as retainers, so bank feed behavior can be checked after each ERPNext release.
Review Plaid coverage and fallbacks periodically, since bank availability can change by country.
Ask for the support scope in writing, covering response expectations, upgrade testing and who handles Plaid account issues.