Deposits Realtime-enabled

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, 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.

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 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 — 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?

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, 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.