Skip to main content
DualEntry links your organization to bank data through financial connections, and there are three ways to establish one. A router connects you through a certified third-party aggregator: you sign in to your bank in the aggregator’s own hosted flow, so credentials are entered there rather than in DualEntry, and the aggregator then pulls account metadata and transactions. An SFTP connection collects a transaction file the bank delivers to a folder, on a daily schedule you set. The Bank Connections API receives a feed pushed from your own systems, built either by your developers or by DualEntry. Which one you use depends on what your bank offers, and most organizations end up with a mix. Whichever way the data arrives, DualEntry stores connection state, linked accounts, and imported financial transactions that you use for reconciliation and bank matching, and everything downstream behaves identically.

​
Where to add a banking connection

You manage every banking connection from a single page in the app. Sign in to DualEntry and navigate to Configuration → Company → Bank Connections, then choose Add Bank Connection to start a new connection. The Bank Connections page lists every connection on the organization, the financial accounts exposed by each one, and the current health of each connection (see Connection status). The same page is where you trigger an on-demand refresh, repair a connection that has dropped into a reconnect state, view the last successful sync timestamp, and remove a connection you no longer need. There is no separate settings area, hidden admin flow, or per-account dashboard; every connection operation routes through this page in both the UI and the API. Adding or repairing connections requires the bank connections permission on the authenticated organization. Users without the permission can still view existing connections and their status when their role allows it, but cannot create, repair, or delete a connection. If you need to add a connection and the Add Bank Connection button is hidden or disabled, ask an admin to grant the permission rather than attempting a workaround through the API.

​
What a banking connection does

A connection represents one consent relationship between your organization and a financial institution (for example, one login at a bank that may expose multiple accounts). DualEntry keeps a financial connection record per organization, tracks status and sync timestamps, and attaches financial accounts (the aggregator’s view of each bank account) to your internal ledger bank accounts where you map them. One connection can fan out into many accounts. A treasury login that exposes a checking account, a sweep account, and three sub-accounts becomes one financial connection with five financial accounts attached. Each financial account is mapped independently to its own GL cash or liability account, so a single bank login still reconciles cleanly to discrete ledger accounts. After data arrives, downstream workflows (reconciliation, rules, and bank match) operate on financial transactions tied to those financial accounts, not on raw aggregator payloads. This abstraction is what lets the same reconciliation, rule, and matching logic apply uniformly however the data arrived: an aggregator-backed connection, an SFTP feed, a connection you built yourself, a manual upload, or a non-standard connection.

​
How to start a connection

Add Bank Connection opens a menu rather than going straight to a bank. Which item you choose depends on what kind of account you are connecting, and the choice is not reversible without deleting the connection and starting again. The two routers both search for your institution and hand you off to that bank’s hosted sign-in; SFTP skips the search and opens a form for the credentials your bank issued instead. Start with the DualEntry Router unless the account is an investment account or your bank has told you it delivers files over SFTP. If you pick the standard router for a brokerage account, the connection succeeds but holdings do not come across, and the fix is to delete the connection and reconnect through the investment router.

​
Investment accounts

Investment and brokerage accounts connect through the same institution search as any other account, but they must be started from Investment Account Router rather than the standard one. Both routers hand you off to the same institution search and hosted sign-in; only the data requested from the aggregator differs. The difference is what DualEntry asks the institution for. The standard router requests account and transaction data, which is everything a checking account has. The investment router additionally requests the investments product, which is what carries holdings. An institution that does not expose investment data through its aggregator will not return holdings regardless of which router you use. Everything after the connection behaves the same way: accounts map to ledger accounts, transactions land as financial transactions, and the same sync, refresh, and repair operations apply.

​
Connection paths and your agreement

Separately from how you start a connection in the app, every account in scope is assigned a commercial path before connections begin. These paths govern coverage and fees, not which button you press. Coverage of the standard path is determined by the certified aggregators and is subject to change at their discretion. SFTP connections sit outside this table. They are self-serve and carry no additional DualEntry fee, though your bank may charge for the feed itself. If a certified aggregator deprecates, throttles, or changes a connection (events DualEntry does not control), DualEntry works in good faith to migrate the affected account to manual upload or a non-standard connection. Migration to a non-standard connection may incur additional fees.

​
Build your own connection

When your own systems already pull transactions from the bank, you can push that feed into DualEntry rather than asking an aggregator to fetch it again. This is the same ingestion path a non-standard connection uses; the difference is only who writes the integration. Your developers register a connection, register the accounts under it, and then push transactions in batches. On registration they can pass a logo image URL so the connection tile shows that image instead of initials. DualEntry does not look up a logo from the bank’s website on this path. The feed appears on the Bank Connections screen like any other, with the institution name you supply, and an accountant maps each account to a GL account and reconciles in Bank Match exactly as they would for an aggregator feed. Two operational differences are worth knowing before you choose this path. DualEntry holds no session with the bank, so there is no reconnect flow: if the feed stops, the fix is on your side, and nothing in DualEntry will prompt anyone. And nothing arrives unless your job pushes it, so the cadence and the completeness of the data are yours to own, the same responsibility that comes with manual upload. If you would rather not build or run that job, ask your account manager about a non-standard connection. DualEntry builds against the same API, subject to feasibility review and the fees in your Order Form. For the endpoints and payloads, see the Bank Connections inbound feed guide and the Bank Connections API reference.

​
Provider coverage and checking whether a bank is supported

DualEntry does not publish a static list of supported banks. Coverage of the standard path is determined by the certified aggregators and changes at their discretion, so the authoritative check is always the in-app institution search rather than a fixed list. Check coverage before you commit an account to a path. On Configuration → Company → Bank Connections, choose Add Bank Connection, then DualEntry Router, and search for the institution by name. A result means a standard connection is available, so you can confirm coverage before starting the sign-in. An institution that returns no result is a candidate for an SFTP feed, a connection you build yourself against the Bank Connections API, manual upload, or a non-standard connection. Each result is labeled with the aggregator that will serve that institution. DualEntry resolves that from the institution’s country and coverage; it is not something you choose, and it can change if an aggregator adds or drops an institution. Treat the label as useful context when troubleshooting a specific bank rather than as a setting. The institution catalog is refreshed on a schedule: daily institution updates plus a weekly full refresh across every provider. An institution that is unavailable today may become available later, so re-run the search before falling back to manual upload. Institution search requires the bank connections view permission and runs in the app only, so an external coverage list cannot be pulled programmatically.

​
Data that syncs and how it maps to your books

Bank data flows in three directions: in from the aggregator, into DualEntry’s internal financial accounts and transactions, and back out to the workflows that act on it. Each direction has different scope and limits, summarized below. Inbound from the bank (read-only aggregation). DualEntry receives the account list, masked identifiers, balances where the aggregator exposes them, and transaction history according to the aggregator’s retention and product settings. Standard connections sync at the cadence supported by the aggregator, typically daily. Feed latency depends on the institution: most banks make transactions available within 1 business day, but some post with a 2-day delay. Pending transactions (authorizations not yet settled) are excluded from the feed to avoid matching against amounts that may change. Inside DualEntry. Each synced external account becomes a financial account linked to your organization. You associate that financial account with a ledger bank account in DualEntry so imported activity lines up with the correct general ledger cash account. Transactions land as financial transactions on that financial account; they are inputs to reconciliation and automation, not automatic journal postings on their own. Historical backfill. The depth of history at initial sync is determined by the aggregator and is typically capped at 90 days. Deeper history must be brought in through a data migration rather than the live feed. Not in scope. Banking connections are read-only. DualEntry does not originate ACH, wire payments, or account changes through these connections.

​
Connection lifecycle and operations

A banking connection moves through a defined lifecycle from initial creation through ongoing sync, periodic refresh, repair when credentials expire, and eventual deletion. DualEntry exposes a discrete operation for each stage so you can drive it from the UI, the API, or background tasks. Create (connect). DualEntry creates a pending connection and returns the aggregator’s hosted flow. You enter credentials, approve any required scopes, and confirm which accounts to expose. Complete. After you finish the hosted flow, DualEntry completes the connection: exchanging tokens with the aggregator where needed, attaching the resolved financial institution, moving the connection out of pending, and enqueueing an initial sync. Sync. A sync refreshes connection metadata, financial accounts, and transaction data from the aggregator into DualEntry. Scheduled and task-driven syncs run in the background; you can also trigger a refresh-and-sync from the UI or API. Refresh. On-demand refresh asks the aggregator for fresher data. DualEntry enforces a per-connection refresh cooldown of 1 hour between manual refresh or refresh-and-sync calls to limit cost and aggregator throttling. Repair / reconnect. When credentials expire or the bank requires re-authentication, the connection moves to a reconnect state. Repair returns a new hosted-flow session in update mode so you can reauthorize without creating a duplicate logical bank link. Delete. Deleting a connection removes aggregator-side access where possible, clears stored credentials, marks the connection inactive, and unlinks ledger accounts that pointed at financial accounts on that connection so your chart of accounts does not reference stale feed accounts.

​
Connection status

Connection status reflects whether DualEntry can currently pull data from the bank and whether anyone needs to take action. Use it as the single signal for connection health on dashboards, alerts, and audit reviews. Statuses are normalized strings on the connection record. The most common values are:
  • pending: connection created but the user has not finished the hosted flow.
  • in_progress: DualEntry is exchanging tokens or running the initial sync.
  • active: the connection is healthy and producing data.
  • partially_active: some accounts are syncing, others are not.
  • reconnect_required: you must reauthenticate, typically due to credential expiry or bank-side MFA.
  • reconnect_available: new accounts are exposed by the aggregator; you can opt to add them.
  • degraded: the aggregator reports intermittent issues and data may lag.
  • expired / deleted: the connection is no longer producing data.
The UI and API surface a reconnectable flag when the connection is in a state that expects user action or when new accounts are available from the aggregator. Timestamps. last_sync_at updates whenever DualEntry runs a sync attempt, successful or not. successfully_aggregated_at reflects the aggregator’s last successful aggregation time when the aggregator supplies it, so it can lag a manual sync click if the bank has not produced new data yet.

​
Customer responsibilities

Once a connection is live, ongoing health depends on actions only the account holder can take. DualEntry monitors connection state and surfaces what needs attention, but cannot satisfy these requirements on your behalf.
  • Credentials. Maintain valid bank credentials at the institution. Password rotations and lockouts at the bank break the connection until you reauthenticate from the Bank Connections page.
  • MFA prompts. Complete multi-factor authentication challenges when the institution presents them during connection or reauthentication. Persistent failure to complete MFA is not a DualEntry support obligation.
  • Reauthentication. Reauthenticate connections in reconnect_required within the cadence your accounting close requires. Stale connections continue to display historical transactions but do not pull new activity.
  • Manual upload cadence. For accounts on manual upload, provide transaction files no less frequently than monthly, by the 5th business day of the following month, in CSV or BAI format. You are responsible for completeness, accuracy, and timeliness of the data you provide.

​
Security and compliance posture

DualEntry enforces several boundaries between your data, the aggregator, and other tenants on the platform. The points below summarize the protections built into the connection layer.
  • No shared secrets in the browser, for aggregator-based connections. Bank passwords for a router-based connection are collected only in the aggregator’s hosted UI, never in DualEntry’s interface or API. SFTP connections are the exception: there is no aggregator to host the credential, so you submit the SFTP password directly to DualEntry.
  • Scoped access. Connection APIs require explicit bank connections permissions on the authenticated organization.
  • Credential storage. Aggregator access tokens and SFTP passwords are both stored in the same encrypted JSON field at rest, and neither is ever returned in plaintext by the API.
  • Transport encryption. All traffic between DualEntry and aggregators runs over TLS, and the aggregator’s hosted flow redirects back to DualEntry over HTTPS only. DualEntry connects to your bank’s SFTP server over SSH, which encrypts the file transfer in transit.
  • Tenant isolation. All connection queries are constrained to the authenticated organization; cross-tenant access is rejected at the API.
  • Webhooks and background work. Aggregator webhooks and background tasks update connection health, pull transactions, and repair stale cursors. Operational logs use structured events suitable for internal monitoring.
Together, these controls encrypt every stored banking credential, whether it came from an aggregator or an SFTP feed, scope every read to a single organization, and produce an event trail your auditors can sample. For platform-level compliance posture, including SOC 2 scope and access logging, see Security and compliance or download the current attestation and policies from the DualEntry Trust Center.
Last modified on September 29, 2026