Banking

Bank Integrations with Yodlee

For enterprise users on our hosted platform, we have integrated with Yodlee, a leading data aggregration platform.

The Yodlee integration links primarily with most of the major US banks, allowing you to link your bank accounts with Invoice Ninja to import your bank transactions for reconciliation.

Loading video...

Credit Card Integrations with GoCardless

We have integrated with GoCardless, a payments integration platform.

The GoCardless integration allows you to link a credit card account from primarily with most of the major EU banks to import transactions for reconciliation.

Connecting your accounts

Settings > Credit Cards & Banks > Connect

Clicking on the connect button with open a new browser window which connects to Yodlee, from this screen you are able to search for your bank and then log into your Bank Account

Once you have successfully authenticated with your bank, you'll be able to select the accounts you wish to link to Invoice Ninja, when this is completed, click save & finish.

Yodlee will give you the opportunity to add more bank accounts from different banks prior to exiting.

info

Tip: If you wish for Invoice Ninja to automatically sync your transaction, turn on Auto Sync. This can be done for each individual Bank Account.

Manually Importing Bank Statements

If you prefer to import your data using .csv files from your bank, you can upload these directly into Invoice Ninja.

You can import these from:

Transactions > Import

You'll need to have created a Bank Account prior to this, so the transactions are linked to the correct bank account.

Transactions

Once data has been imported into Invoice Ninja, this can be viewed from the Transactions tab in the sidebar.

For more details on Transactions, see Transactions

Bank Rules

To improve your efficiency, you can build a ruleset to match your incoming transactions. Using a rule set will allow Invoice Ninja to perform the matching and/or conversion of transactions for you.

There are two types of bank rules — credit rules for incoming payments and debit rules for outgoing payments:

	Credit Rules	Debit Rules
Direction	Money in	Money out
Purpose	Match transactions to invoices or payments	Categorise transactions as expenses
Searchable fields	Invoice, payment, and client fields (18 total)	Description and amount only
Auto-convert creates	A payment record	An expense record
Assignment targets	Invoice and/or client (automatic)	Vendor and expense category (manual)

Creating a Rule

To create a bank rule, navigate to:

Settings > Credit Cards & Banks > Rules

You can edit and create rules from this page — simply click on a rule, or the create button to create a new bank rule.

Each rule has the following settings:

Setting	Description
Name	A label for your own reference (e.g. "Stripe deposits", "Office rent")
Applies to	CREDIT or DEBIT — determines which transactions this rule evaluates
Match all / Match any	Whether all conditions must be true, or any one is sufficient
Auto-convert	When enabled, automatically creates a payment or expense on match
Conditions	One or more conditions that define what to look for (see below)

Debit-specific settings

Setting	Description
Vendor	The vendor to assign to matched transactions
Expense category	The expense category to assign to matched transactions

---

Conditions

Every rule contains one or more conditions. Each condition has three parts:

Part	Description
Field	What to search (differs between credit and debit rules)
Operator	How to compare
Value	What to compare against

Operators

String operators — used with text fields like description, invoice number, email:

Operator	Behaviour
is	Exact match (case-insensitive, ignores spaces)
contains	The transaction description includes the value anywhere
starts_with	The transaction description begins with the value
is_empty	The field has no value

info

String matching is case-insensitive and strips spaces before comparing. For example, a rule value of "acme corp" matches a description containing "AcmeCorp".

Numeric operators — used with amount fields:

Operator	Behaviour
=	Amount equals the value
>	Amount is greater than the value
>=	Amount is greater than or equal to the value
<	Amount is less than the value
<=	Amount is less than or equal to the value

---

Credit Rules — Matching Incoming Payments

Credit rules search the bank transaction's description against your existing invoices, payments, and clients to find the best match.

Available Search Fields

Credit rules can match against a rich set of fields across three entity types:

Invoice fields:

Field	Description	Matching method
$invoice.number	Invoice number (e.g. INV-0001)	Searches for the invoice number as a whole word in the transaction description
$invoice.po_number	Purchase order number	String operator against transaction description
$invoice.amount	Invoice balance	Numeric operator comparing transaction amount to invoice amount
$invoice.custom1 – $invoice.custom4	Invoice custom fields	String operator against transaction description

Payment fields:

Field	Description	Matching method
$payment.amount	Payment amount	Numeric operator comparing transaction amount to payment amount
$payment.transaction_reference	Payment reference / check number	String operator against transaction description
$payment.custom1 – $payment.custom4	Payment custom fields	String operator against transaction description

Client fields:

Field	Description	Matching method
$client.id_number	Client ID number	String operator against transaction description
$client.email	Client contact email address	String operator against transaction description
$client.custom1 – $client.custom4	Client custom fields	String operator against transaction description

tip

Client fields work best as secondary conditions combined with invoice or payment fields. When both are present, the system cross-references them to find the invoice or payment that belongs to that specific client — dramatically improving accuracy when multiple invoices share similar amounts.

How Credit Matching Works

When a credit transaction is evaluated, the system searches for matches across all conditions in the rule. Once the conditions are met (all match, or any match, depending on your setting), the system resolves the best result using a priority order:

1. Invoice number — A direct invoice number match in the description is the strongest signal. If found, the transaction is linked to that invoice immediately.

2. Invoice PO number — If no invoice number matched, PO number matches are considered. When a client condition also matched, the system cross-references to find the invoice belonging to that client.

3. Invoice amount — Invoices whose amount matches the transaction amount. Again, client conditions narrow the results.

4. Invoice custom fields — Custom field matches on invoices, narrowed by client when available.

5. Payment amount — Existing unlinked payments whose amount matches the transaction.

6. Payment reference — Payments whose transaction reference appears in the description.

7. Payment custom fields — Custom field matches on existing payments.

At each priority level, if a client condition (email or ID number) also matched, the system first tries to find a result that belongs to that client before falling back to the first available match.

info

Only the first matching rule is applied to each transaction. Rules are evaluated in order, and processing stops after the first successful match. Design your most specific rules first.

What Happens on Match

• The transaction status changes from Unmatched to Matched
• The matched invoice or payment is linked to the transaction
• If auto-convert is enabled, a payment record is created automatically and the transaction status becomes Converted

Which Invoices and Payments Are Considered

• Invoices with status Draft, Sent, or Partial — excluding deleted invoices
• Payments with status Pending or Completed — excluding deleted payments and payments already linked to a bank transaction

---

Debit Rules — Categorising Outgoing Payments

Debit rules are simpler. They match against the transaction's own fields and assign a vendor and expense category.

Available Search Fields

Field	Operator type	Description
description	String	The bank transaction description text
amount	Numeric	The bank transaction amount

Examples

Match a specific vendor by description:

Field: description, Operator: contains, Value: "Amazon Web Services" Vendor: AWS, Category: Hosting

Match rent payments by amount:

Field: amount, Operator: =, Value: 2500.00 Field: description, Operator: contains, Value: "Property Management" Match: All conditions Vendor: ABC Property, Category: Rent

Match any small purchase from a supplier:

Field: description, Operator: starts_with, Value: "OFFICEWORKS" Vendor: Officeworks, Category: Office Supplies

What Happens on Match

• The transaction status changes to Matched
• The vendor and expense category from the rule are assigned to the transaction
• If auto-convert is enabled, an expense record is created automatically with:
  • The rule's vendor and category
  • The transaction amount and currency
  • The transaction date as both the expense date and payment date
  • The transaction description as the expense reference
  • The transaction status becomes Converted

tip

If no expense category is set on the rule, the system attempts to resolve one from the bank's own category mapping. Set an explicit category on the rule for predictable results.

---

Match All vs Match Any

This setting controls how multiple conditions within a single rule are evaluated:

• Match all — Every condition in the rule must be true. Use this for precise matching when you want to combine criteria (e.g. amount equals $500 AND description contains "Acme").
• Match any — At least one condition must be true. Use this for broader matching when any single signal is sufficient.

Example: Match All

A rule with two conditions and Match all enabled:

Condition	Field	Operator	Value
1	$invoice.amount	=	(transaction amount compared to invoice amount)
2	$client.email	contains	(client email found in description)

Both must match. This finds transactions where the amount matches an open invoice AND the client's email appears in the description — a strong, specific match.

Example: Match Any

A rule with two conditions and Match any enabled:

Condition	Field	Operator	Value
1	$invoice.number	—	(invoice number found in description)
2	$payment.transaction_reference	contains	(payment reference found in description)

Either can match. This catches transactions that reference an invoice number OR a payment reference.

---

Auto-Convert

When auto-convert is enabled on a rule, matched transactions are immediately processed without manual intervention:

Rule type	Auto-convert action
Credit	Creates a payment record against the matched invoice, marking the invoice as paid
Debit	Creates an expense record with the vendor, category, amount, and date from the transaction

After auto-conversion, the transaction status moves directly from Unmatched to Converted, skipping the intermediate Matched state.

warning

Auto-convert creates real financial records (payments and expenses) automatically. Test your rules with auto-convert disabled first to verify they match the correct transactions before enabling it.

---

Transaction Statuses

Status	Description
Unmatched	No rule has matched this transaction yet
Matched	A rule matched and linked an invoice/payment or assigned a vendor/category, but no record was created
Converted	A payment or expense record was created from this transaction

---

Tips for Effective Rules

1. Be specific with credit rules. Combine invoice fields with client fields for accurate matching. A rule matching $invoice.amount alone may match the wrong invoice when multiple invoices share the same amount.

2. Use invoice number matching when possible. If your payment processor includes the invoice number in the bank description, $invoice.number provides the most reliable match — it searches for the number as a distinct word boundary in the description.

3. Order matters. The first matching rule wins. Place your most specific rules first and broader catch-all rules last.

4. Start without auto-convert. Create your rules with auto-convert disabled, let them run against incoming transactions, review the matches, and only enable auto-convert once you're confident in the results.

5. Use Match All for precision. When combining amount matching with client identification, use Match All to ensure both conditions are satisfied before linking.

6. Keep debit rules simple. Since debit rules only match on description and amount, use clear, distinctive keywords from your bank statements. Check your bank's actual transaction descriptions to find consistent patterns.

7. Leverage custom fields. If you store reference codes, project IDs, or account numbers in custom fields on invoices, payments, or clients, you can use them as matching criteria for credit rules.