Payment Proposals in D365 Finance: Setup and Controls

May 24
4 min read

A payment proposal in Dynamics 365 Finance is a query against open vendor transactions. You set the criteria, and Dynamics 365 Finance returns the matching invoices, written as lines into a vendor payment journal, ready for review.

The proposal types are Due date, Cash discount, and Due date and cash discount. The due date selects invoices whose due date falls in the range you set. Cash discount selects invoices whose discount date falls in the range, so they're paid early enough to keep the discount. Due date and cash discount combine both so that a single proposal can pick up routine payments and time-sensitive discounts in one pass.

One-off payments, prepayments, and manual adjustments still go in via direct journal entry. The proposal is the volume path.

Creating a payment proposal and filtering by due date, discount, or vendor

From the vendor payment journal, open a new journal, go to Lines, and select Payment proposal > Create payment proposal. The dialogue has three sections.

Proposal type and date range. Choose Due date, Cash discount, or both, then enter the from and to dates. For a cash discount proposal with a range of 26 June to 10 July, the proposal includes invoices whose discount date falls in that range.

Records to include. This is a query builder against the vendor transactions table. The file format generated downstream is method-specific, so running one proposal per method of payment keeps each output file clean.

Advanced parameters. Minimum payment date sets a floor for the payment date assigned to selected invoices. Amount limit caps the total cash going out in this run. For Italian legal entities, an additional Use future due date parameter changes how the payment date is calculated for invoices due after the minimum payment date.

With the Public sector configuration key turned off, vendor bank account edits made during the proposal stage flow to the resulting journal lines. With the key on, those edits stay isolated. Outside public-sector implementations, that isolation has to be achieved separately through master data approval workflows on the vendor record.

Reviewing, modifying, and generating the payment file

The proposal output is journal lines, not posted entries. Nothing reaches the ledger or the bank until AP reviews each line and posts the journal.

Lines are editable individually. The Settle transactions link shows which invoices each payment will close, which matters whenever one payment covers multiple invoices or a partial payment needs to be allocated.

Once the journal is correct, Generate payments produces the electronic file. The file format is driven by the method of payment, which points to either a built-in payment format or an Electronic reporting configuration. ISO 20022 credit transfer is the standard format for SEPA-region payments.

The output is a file ready to upload to the bank portal or transmit via a bank integration. The journal is then posted, which commits the ledger transactions: vendor accounts cleared, bank account debited.

Payment controls and positive pay: what to configure before go-live

Four controls determine whether the first month of live payments runs cleanly or generates rework.

Methods of payment. Each method links a payment format to a bank account, with its own approval requirements. A misconfigured method at go-live can route domestic GBP payments through a SEPA EUR format, and the bank will keep rejecting the file until someone diagnoses the mismatch.

Vendor bank account changes. The path from a fraudulent email to an unauthorised payment runs through this field. The mitigation is workflow approval on changes to vendor bank details, with callback verification as a second layer. The configuration lives outside the payment proposal itself but determines whether the proposal can be trusted.

Payment journal approval. This is a separate workflow from the AP invoice approval that happens earlier in the procure-to-pay cycle. It enforces segregation of duties at the point where money leaves: the person who runs the proposal isn't the person who posts the journal.

Positive pay. Positive pay generates an electronic list of issued checks that's transmitted to the bank. When a check is presented for clearing, the bank compares it against the list, and mismatches are held for review. The current setup uses Electronic reporting; the non-ER configuration was deprecated in September 2022. Set up work lives under Cash and bank management: import the Microsoft-supplied Positive pay model and format, then assign the format and a start date to each bank account that should generate files. After every check run, the file comes out of Bank accounts > Manage payments > Positive pay.

Training an AP team on payment proposals and the wider vendor payments cycle?

Start with our free user training starter kit, a 3-step video course with two downloadable templates for planning training around real D365 transactions.