# Deposits _(Realtime-enabled)_

`GET` `POST` `PATCH` `DELETE` _(Table: EONE Transaction)_

```
eOne/core/v1.0/deposits
```

One bank credit that settles documents for **many** customers or vendors. A lockbox file, a direct-debit collection run, a payment processor's payout. Posts one bank ledger entry and one party line per party, so the bank reconciles against the statement line that actually arrived.

## What this is for

Money often arrives in one lump covering many people.

A lockbox file lands as a single bank credit with a remittance list. GoCardless or a BACS collection run pays out the week's mandates together. A card processor settles hundreds of customers' payments as one transfer. In every case the bank statement shows **one** line.

Sent as separate [customer payments](https://eonesolutions.github.io/eone-bc-integration/core-customerPayments.md), that becomes one bank ledger entry per customer. Two hundred payers, two hundred bank entries, one statement line — and the reconciliation is then done by hand, every time.

A deposit posts what Business Central's own Cash Receipt Journal posts: one bank line, one party line per party, one balanced document. The result in the ledger is ordinary Business Central.

## The party is on the line

This is the one structural difference from every other endpoint here, and everything else follows from it.

The header carries the bank account and the total that arrived. It has **no** customer or vendor. Each `depositApplication` names its own party — `accountType` plus `accountNumber`, or `accountIntegrationId` to resolve one by your external key — and settles a document belonging to **that** party.

```http
POST /deposits
{ "documentNumber": "LOCKBOX-4471", "postingDate": "2026-09-01",
  "balancingAccountType": "Bank Account", "balancingAccountNumber": "CHECKING",
  "amount": 12450.00, "expectedLineCount": 3, "declaredTotalAmount": 12450.00 }

POST /deposits({id})/depositApplications
{ "accountIntegrationId": "CRM-8842", "appliesToInvoiceNumber": "PS-1041", "amount": 4200.00 }
```

Party, open-ness and remaining amount are all checked against the **line's** party. A line that names a document belonging to somebody else is refused with both names, exactly as a single-party payment would be — the rule has not been relaxed, it has moved one level down.

## One party line per party

A customer who settles three of their invoices in one deposit gets **one** receipt on their statement, carrying an applies-to id, with three detailed entries doing the closing. Not three receipts. That is what a single [customer payment](https://eonesolutions.github.io/eone-bc-integration/core-customerPayments.md) does for one customer, and a deposit does it for each party independently.

Each party's settlement gets its own applies-to id. This matters more than it looks: posting matches a party line to its ledger entries by party **and** that id, so a single id shared across the deposit would stamp every party's open entries alike. The journal balances either way — which means cash settling against the wrong customer's invoice would report nothing at all.

## Every penny has to be accounted for

On a single-party payment the header amount is a ceiling: apply less than it and the difference sits on that customer's account, unapplied, waiting for a later apply. That is standard behaviour and it is left alone.

A deposit has no such party. An unexplained remainder belongs to nobody in particular, and crediting the first line's customer would be a silent invention. So the whole amount must be either applied to a document or distributed to an account, and anything left over is **refused by name** with the figure.

Two ways to account for the rest:

- **[Distributions](https://eonesolutions.github.io/eone-bc-integration/core-distributions.md)** — for anything that is not a settlement: income with no receivable behind it, a write-off, a rounding difference.
- **`deductionAmount` / `deductionAccountNumber`** — for a provider's fee withheld *before* the money reached the bank. Every party is credited what they actually paid, the fee posts to its own account, and the bank line takes only what arrived.

## Set expectedLineCount

It matters here more than on any other endpoint.

A two-hundred-customer lockbox is built over two hundred calls, and each one resets the five-minute idle window that decides when a staged document is ready. Without `expectedLineCount` the deposit only processes once the calls stop. With it, the deposit goes as soon as that many lines have arrived — and a half-arrived batch is never processed.

Pair it with `declaredTotalAmount` for a file that must reconcile to the bank exactly. The deposit then fails with the difference stated rather than posting a batch that does not match the statement.

## Deposits or customerPayments?

| Use | When |
| --- | --- |
| [`customerPayments`](https://eonesolutions.github.io/eone-bc-integration/core-customerPayments.md) | One payer, one payment. The overwhelmingly common case, and unchanged. |
| `deposits` | One bank credit covering several payers, where you want one bank entry to reconcile. |

A deposit with a single party is legal and posts identically to a payment — but there is no reason to reach for it.

## Bound actions

Same three as every journal wrapper, with the same meanings.

- **`validate`** — run the checks and write nothing. Worth calling on a large batch before processing.
- **`process`** — write the journal lines and delete the staged document.
- **`post`** — process and post this deposit alone, whatever the endpoint's Processing Mode says. Still refused when the endpoint requires approval and the deposit has none.

Because the staged document deletes itself once its journal lines exist, `process` and `post` return no body. Read the outcome from [`processedDocuments`](https://eonesolutions.github.io/eone-bc-integration/core-processedDocuments.md), filtering on the `integrationId` you sent.

## What a DELETE may do

A staged deposit that is pending approval or already approved cannot be deleted; cancel the approval request or reopen it first, so what the approver signed off on is what posts. A DELETE is also refused when the endpoint's **Allow Manual Delete** switch is off on the eOne Integration Setup page. It is on by default, so nothing changes until an administrator turns it off to mark deposits integration-owned.

## Deposits fields

_API column → BC field._

**Legend**

- _(req)_ required on create
- _(res)_ resolver
- _(cur)_ currency-translated
- _(ro)_ read-only
- _(ext)_ added to this endpoint by another extension (BC field name shown; its API column name is not known here)

| API | BC field | Notes |
| --- | --- | --- |
| `id` | SystemId | BC record GUID. _(ro)_ |
| `bcCompanyId` | bcCompanyId | The company this row belongs to - the same GUID that appears in the request URL. Present on every endpoint so a store pooling several companies can keep them apart without relying on which URL it called. _(ro)_ |
| `bcCompanyName` | bcCompanyName | The name of the company this row belongs to. _(ro)_ |
| `integrationId` | EONE Integration Id | Your external key for the deposit - the lockbox batch or payout id it came from. See Integration Id. |
| `documentNumber` | Document No. | Deposit document number. Every journal line the deposit writes carries it, which is what makes the bank line and its party lines one balanced document. |
| `postingDate` | Posting Date | Date the deposit posts to - normally the date the money reached the bank. |
| `documentDate` | Document Date | The document's own date; defaults to the posting date when left blank. |
| `externalDocumentNumber` | External Document No. | Caller's reference number. |
| `currencyCode` | currencyCode | ISO code; blank is LCY. _(cur)_ |
| `balancingAccountType` | Bal. Account Type | Cash side: bank or G/L account. This is the ONE line the whole deposit balances to. |
| `balancingAccountId` | balancingAccountId | GUID of the resolved bank/G/L balancing account. _(ro)_ |
| `balancingAccountNumber` | Bal. Account No. | No. of the bank or G/L account the deposit hits - the single line the bank statement reconciles against. |
| `amount` | Amount | The total that arrived in the bank. Unlike a single-party payment this is not a ceiling with a remainder: every part of it must be either applied to a document or distributed to an account, because a deposit has no one party whose account an unexplained remainder could sit on. |
| `pricesIncludeTax` | Prices Include Tax | Whether distribution line amounts already include tax. Applications are unaffected - they settle a document that was taxed when it was raised. See Journal Wrappers. |
| `appliedAmount` | Applied Amount | Sum of the application lines across all parties. _(ro)_ |
| `numberOfApplications` | No. of Applications | How many application lines the deposit has, across all parties. _(ro)_ |
| `applicationsResolved` | Applications Resolved | How many application lines already point at a posted document and are ready to apply. _(ro)_ |
| `applicationsAwaitingInvoice` | Applications Awaiting Invoice | How many application lines name a document by integrationId that has not posted yet. Greater than zero is what puts the deposit in status Awaiting Invoice. _(ro)_ |
| `description` | Description | Free-text description. |
| `expectedLineCount` | Expected Line Count | How many lines this deposit will have when it is complete. It matters more here than anywhere else: a two-hundred-customer lockbox is built over two hundred calls, each of which resets the five-minute idle window, so without this the deposit only processes once the calls stop. Set it and the deposit goes as soon as that many have arrived - and a half-arrived batch is never processed. |
| `declaredTotalAmount` | Declared Total Amount | The total you believe the lines add up to. When set and the arrived lines do not match, the deposit fails with the difference stated rather than posting. For a lockbox file that must reconcile to the bank exactly, this is the check worth setting. |
| `deductionAmount` | Deduction Amount | An amount a third party withheld before the money reached the bank - a collection provider's fee. Every party is credited what they actually paid, this is booked to its own account, and the bank line takes only what arrived. Positive magnitude; the engine derives the sign. |
| `deductionAccountNumber` | Deduction Account No. | G/L account the withheld amount is booked to. Required whenever deductionAmount is set, and vice versa. |
| `status` | Status | Where the deposit is in the staged lifecycle. Read-only. See Document Workflow. _(ro)_ |
| `errorMessage` | Error Message | Why the deposit could not be processed. Read-only. _(ro)_ |
| `journalTemplateName` | Journal Template Name | General journal template the deposit posts through; defaults from the endpoint setup. |
| `journalBatchName` | Journal Batch Name | General journal batch the deposit posts through; defaults from the endpoint setup. |
| `shortcutDimension1Code` | Shortcut Dimension 1 Code | Dimension applied to every journal line of the deposit. See Dimensions. |
| `shortcutDimension2Code` | Shortcut Dimension 2 Code | Dimension applied to every journal line of the deposit. See Dimensions. |
| `createdDateTime` | SystemCreatedAt | When the integration imported this deposit into staging. _(ro)_ |
| `lastModifiedDateTime` | SystemModifiedAt | _(ro)_ |

## Related pages

Collections nested under this endpoint:

- [Deposit Applications](https://eonesolutions.github.io/eone-bc-integration/core-depositApplications.md)
- [Distributions](https://eonesolutions.github.io/eone-bc-integration/core-distributions.md)