Distributions Realtime-enabled

Code a ledger document across several accounts instead of one. Each line books part of the document to an account (accountNumber), with its own dimensions and description. A nested collection shared by all nine party endpoints: customerInvoices({id})/distributions, customerPayments({id})/distributions, and so on.

What this is for

A customer invoice with no distributions posts two journal lines: the customer, and the header's balancingAccountNumber. That is the whole revenue side on one account.

Distributions split it. A subscription invoice covering a plan fee, a usage overage and a one-off setup charge is three lines here, each to its own revenue account, and still one customer receivable. The same applies on the purchase side: an AP invoice arriving from an approval tool already coded across several expense accounts is one vendor payable and N distribution lines.

Each line carries its own shortcutDimension1Code..8Code, which is the reason to reach for this rather than several documents. A document spanning two departments or two product lines cannot be dimensioned per department if the whole amount is one line.

They may total less than the document, never more

amount on the header stays the document total. The distributions are a ceiling under it, and on a payment or refund that ceiling covers the applications and the distributions together.

• Totalling the document amount — on an invoice, no balancing line is written at all and balancingAccountNumber stops being required. On a payment, nothing is left on the party's account.
• Totalling less — the difference goes where it would have gone anyway: to the balancing account on an invoice, or onto the party's account unapplied on a payment.
• Totalling more — rejected, naming both figures. Nothing on the header funds the excess.

On a payment the combined check matters more than it looks. Sixty applied plus sixty distributed against a header of a hundred would pass two separate checks and still balance, because the bank plug absorbs it — and the party would be credited sixty more than they ever paid.

Amounts are sent as positive magnitudes, like everywhere else in the journal wrappers; the endpoint derives the side each line posts to from the document type.

Which side a line lands on depends on the parent

This is the one thing to understand before using them, and it follows from what the header amount means.

On an invoice or credit memo the amount is the party movement. The party line takes all of it, and the distributions are the offsetting side — an invoice debits the customer and credits revenue.

On a payment or refund the amount is the cash, and the bank takes all of it. The party line takes only the part that settles something; a distribution takes another part of the same side. So the applications and the distributions share the header amount:

customerPayments  amount 100.00
  applications   60.00   settles the membership invoice
  distributions  40.00   donation income, account 41200

  Customer        credit   60.00
  Donation income credit   40.00
  Bank            debit   100.00

That is the membership-renewal-plus-donation case. Without a distribution the 40 would land on the member's account as an unapplied credit they never paid, and the donation would never be recognised as income at all.

You always send a positive amount on the line. The engine sets the sign, exactly as it does for every other amount in the journal wrappers.

Accounts other than G/L

accountType defaults to G/L Account, which is what an invoice's revenue or expense side almost always is. It also accepts Bank Account, Customer, Vendor, Employee and Fixed Asset, for the cases where a coded line genuinely belongs to a subledger rather than to the general ledger.

Line type

Distributions and applications are rows in one staging table, told apart by a line type. You never send it: this collection stamps Distribution on everything it creates, and the applications collections stamp Application on theirs. Each collection lists only its own kind, so distributions never shows an application and customerPaymentApplications never shows a distribution.