# Recording Bank Transactions Where Bank Feeds Are Not Available

[Bank Feeds](/guides/bank-feeds) is Apideck's purpose-built resource for pushing bank and card transactions into an accounting system for reconciliation. It's live on the connectors in the [Bank Feeds coverage table](/guides/bank-feeds#resource-mapping). For every other accounting connector, there is no equivalent write today — and for some of them, there likely never will be, because the underlying platform doesn't expose one.

When you still need to get a bank or cash movement into the ledger on one of those connectors, `journal-entries` can act as a manual substitute: a debit line and a credit line that together represent the transaction. This guide covers how to do that, which connectors support it, and — just as importantly — what you give up by using a journal entry instead of a real bank feed.

>
> This is a fallback, not a bank feed. If a connector you need shows up on the [Bank Feeds](/guides/bank-feeds) coverage table, use that resource instead — it gives you reconciliation matching, a pending/review state, and balance validation that a journal entry cannot.

---

## 1. Which connectors this applies to

Journal entries are supported on the large majority of Apideck's accounting connectors. This guide is for the ones that also have **no native Bank Feeds write** — where journal-entries is your path to recording a bank or cash movement, not just an alternative to one.

Three connectors need connector-specific handling, covered in their own sections below:

| Connector | Notes |
| --- | --- |
| [AFAS](#afas) | Falls back to an Apideck-generated placeholder voucher number if you don't supply one |
| [Visma e-accounting](#visma-e-accounting) | Requires the ledger account's nominal code, not its id |
| [Microsoft Dynamics 365 Business Central](#microsoft-dynamics-365-business-central) | Multi-call write with rollback on failure — see the [dedicated journal entries guide](/guides/journal-entries-expenses-mbc) for the full batch/posting model |

The rest take the standard `line_items` mapping shown in [Section 2](#2-recording-a-transaction-as-a-journal-entry) with no connector-specific caveats: Fortnox, SAP S/4HANA Cloud, Spiris, Yuki, QuickBooks Desktop, Procountor Fi, MRI Software, Acumatica, Workday, MYOB Business, MYOB-Acumatica, Restaurant365, Alegra, Holded, DualEntry, e-Boekhouden, e-conomic, Fiken, Minox, Oracle Fusion, and Intuit Enterprise Suite. One exception: Wafeq's availability depends on your Wafeq plan tier.

---

## 2. Recording a transaction as a journal entry

The shape is the same across connectors: two balancing lines, one for the bank/cash account, one for whatever the movement represents.

```http
POST https://unify.apideck.com/accounting/journal-entries
Authorization: Bearer {API_KEY}
x-apideck-app-id: {APP_ID}
x-apideck-consumer-id: {CONSUMER_ID}
x-apideck-service-id: afas
Content-Type: application/json
```

```json
{
  "posted_at": "2026-04-05T00:00:00.000Z",
  "memo": "Customer payment — Acme Corp",
  "line_items": [
    {
      "type": "debit",
      "total_amount": 500.0,
      "description": "Bank account — receipt",
      "ledger_account": { "id": "1010" }
    },
    {
      "type": "credit",
      "total_amount": -500.0,
      "description": "Customer payment — Acme Corp",
      "ledger_account": { "id": "1300" }
    }
  ]
}
```

Debits are positive and credits are negative, so the lines sum to zero, and `posted_at` is a full ISO 8601 timestamp, not a date. Send this to [`POST /accounting/journal-entries`](/apis/accounting/reference#operation/journalEntriesAdd). Unlike a Bank Feed statement, there's no `bank_feed_account_id` to register up front and no separate account-linking step — you supply both ledger accounts directly on the entry.

### AFAS

If you omit `number`, Apideck's connector fills in a placeholder voucher number rather than requiring one up front — this isn't AFAS's own native auto-numbering, so don't expect it to match AFAS's internal voucher sequence. The accounting year and period are derived from `posted_at` — there's no separate field for either. Each line needs `ledger_account.id`; there's no code-based alternative.

### Visma e-accounting

Each line needs `ledger_account.nominal_code`, not `ledger_account.id` on its own. `posted_at` is truncated to a date before being sent — any time component is dropped.

### Microsoft Dynamics 365 Business Central

Business Central has no native "journal entry" object — Apideck's connector builds one from general journal lines under the hood. This isn't a single atomic call: the first line posts immediately, the remaining lines are created one at a time, the batch is then optionally posted, and if a later step fails the connector calls an explicit compensating rollback to remove what it already wrote. That rollback is a best-effort cleanup, not a database transaction — if the rollback call itself fails, you can be left with a partially-written entry, so treat a failure response as something to verify against the ledger, not assume was fully undone. This mirrors the bookkeeping model covered in depth in [Using Journal Entries and Expenses with Microsoft Business Central](/guides/journal-entries-expenses-mbc), including required one-time journal batch setup in the Apideck Dashboard.

---

## 3. What you give up compared to a real bank feed

A journal entry and a bank-feed statement line both end up as a dated, amounted GL movement. They are not the same thing underneath, and the difference matters once you're relying on this for real reconciliation.

**No reconciliation identity.** A Bank Feed transaction carries a `source_transaction_id` the accounting system can match against anything it separately imports. A journal entry has no such link — if the connector's platform also runs its own native bank feed, the same movement can land twice, and someone has to spot and clear the duplicate by hand.

**You choose both ledger accounts yourself.** A Bank Feed statement is scoped to a `bank_feed_account_id`; the accounting system already knows which GL account the money landed in, and lets the user categorize the other side inside its own reconciliation UI. A journal entry needs both sides specified up front — the categorization decision has to happen in your integration, not in the accounting software.

**No pending state.** Bank Feed lines sit "for review" until a user matches them. Journal entries in most of these connectors post as final, immutable records immediately — correcting one later means a new reversing entry, not an edit, and it shows up in the ledger as two lines instead of one clean feed transaction.

**No balance validation.** Bank Feed statements (on connectors that support it, like Xero) validate opening and closing balances and reject gaps or overlaps between periods — a structural safeguard against a missed or duplicated import. A journal entry has no equivalent check.

**No audit trail back to the source.** A Bank Feed transaction is typically visible in the accounting software's own UI as imported from an external feed. A journal entry looks identical to something a bookkeeper typed by hand.

None of this makes the journal-entries approach wrong to use — it's a legitimate way to get a bank movement recorded today on a connector without Bank Feeds support. It does mean you should treat it as a manual entry with all the manual-entry tradeoffs, not as bank feed parity.

---

## FAQ

**Should I use this instead of Bank Feeds on a connector that supports both?**
No. If a connector is on the [Bank Feeds coverage table](/guides/bank-feeds#resource-mapping), use `bank-feed-statements` there — it gives you reconciliation matching and balance validation this fallback doesn't have.

**Can I update a journal entry after posting it, if I made a mistake?**
Depends on the connector, but in most cases: no, not once it's posted. Post a reversing entry instead — see each connector's own `journal-entries` gotchas in the [Accounting API reference](/apis/accounting/reference#tag/Journal-Entries) for specifics.

**How do I avoid double-counting if the connector later gets a native bank feed?**
There's no built-in dedup between a journal entry and a future Bank Feed import — the journal entry has no source transaction id for the accounting system to match against. If you migrate a connector to native Bank Feeds support later, stop writing journal entries for that account going forward rather than running both.

**Which connectors should I start with?**
Any connector listed in [Section 1](#1-which-connectors-this-applies-to) — `journal-entries` is a well-established resource across this list. Run your own test against a sandbox before shipping to production, the same way you would for any new write path.

## Next steps

- [Bank Feeds overview](/guides/bank-feeds) — the resource to use wherever it's supported
- [Using Journal Entries and Expenses with Microsoft Business Central](/guides/journal-entries-expenses-mbc) — full detail on Business Central's batch/posting model
- Reference: [Journal Entries](/apis/accounting/reference#tag/Journal-Entries)