Skip to content
Copy site link for AI

Employee Payment Applications Realtime-enabled — SmartConnect can trigger on changesRealtime-enabled

GETPOSTPATCHDELETETable: EONE Transaction Line

eOne/core/v1.0/employeePaymentApplications

The distribution lines of an employee payment. Each row carries part of the reimbursement, optionally with a comment that flows onto the journal line description. A nested collection addressed under its parent: employeePayments({id})/employeePaymentApplications.

Unlike the customer and vendor sides, an employee reimbursement is not settled against a posted invoice. Each line splits the reimbursement amount and can carry a free-text comment. A line can also name the expense report it settles.

The parent supplies the payment key; lineNumber is stamped automatically on insert. Deep-insert the lines with the parent, or POST them under the payment's employeePaymentApplications collection.

A line with no target is the on-account line

A line that names no expense report posts against the employee unapplied, and its comment becomes the journal line description. When the lines total less than the parent amount, the engine adds exactly that line for the shortfall, so a reimbursement can pay part of what is owed and leave the rest on the employee's account. Applications totalling more than the parent amount are rejected, naming both figures.

Lines that do name an expense report are settled together, as one employee ledger entry for their total. A comment therefore reaches the journal line description only on a line that settles nothing, or on a reimbursement settling a single report. Every comment is kept against the processed document in the eOne Processed Documents history.

Settle an expense report by your own key

appliesToExpenseIntegrationId is a resolver that finds the report's posted document by your own Integration Id, and fills in appliesToDocumentNumber for you. It resolves when you POST the line, so a wrong key, a report belonging to another employee, or an entry that is already settled is reported to SmartConnect straight away.

If the expense has not posted yet, the payment waits in staging and applies once it posts. Turn off Allow Before Invoice Posts on the endpoint and the unresolved key is rejected on POST instead. That setting had no effect on this endpoint before, because the key was only resolved when the document was processed.

Application targets must be open

Where a line does name a target, by appliesToDocumentNumber or by the expense's appliesToExpenseIntegrationId, the same open-entry rules apply, read from the employee ledger: a reimbursement cannot be applied to an entry that is already settled, and an applied total above what remains on that entry is rejected naming the document, its remainder and your total. A key resolving to a closed entry reports that it is closed rather than waiting for an expense that has already posted. The Payment Applications page in Business Central now offers a lookup here too, listing the employee's open entries with the amount remaining on each.