Currently you can either have a custom model or the standard Microsoft maintained model.

In terms of general understanding for the invoice the standard MS one works well enough but for some suppliers there is additional complexity which the standard model will not handle.

We should not have to run a highly complex custom model to try to cater for all vendor scenarios and standard scenarios.

By adding the ability to identify a custom model at a vendor we would be able to collect the additional or complex information as needed for that supplier. This would mean that we would need to run the standard model first to collect the data it can to understand the vendor in order to run the additional custom model. That is understood and accepted.

If there is no custom model defined then just keep going with the standard process.

Each cost invoice captured by the app is currently created as a sperate Invoice Journal in D365 Finance - i.e. a one-to-one relatonship between invoice an Invoice Journal.

This causes a lot of records on the invoice journal grid and makes it hard to navigate and search for a specific journal. In addition the description on each journal is vague which makes the task of looking for a particular journal even more difficult.

Suggestion: Group all cost invocie over a given period of time in one journal - where each invoice is a separate voucher within the journal. The attachments would be at the voucher level.

Our customers are requesting the ability to configure notifications in Invoice Capture, such as emails or alerts, that can be sent to AP users. This would allow them to follow up on invoices with errors that have not been transferred to D365F&O.

Notifications would be extremely helpful, as they would eliminate the need for users to log into Invoice Capture or the workspace, which can sometimes be limiting.

Since multiple customers have requested this feature and we believe it would greatly benefit them, we would like you to consider this improvement for future versions

Settle and post sales taxes does not consider the functionality “Vat report date codes” and cause that the company pay wrong taxes.

Issue was escalated under ID 756139 but it was rejected for now due to fact that the 'vat report date codes' were never supported by the "sales tax payment"

Link to LCS: Details for issue 756139 (dynamics.com)

Configurations that we import from Microsoft repositories misses release note to find which changes have been made on data model, model mapping and format designer.

This will help user to get better overview that each KB or ID include in regards with new fields functions, changed mapping and deleted fields.

As an example, It could be added a text field as attachment regarding the changes as "Release note" or a new field on mapping model and format designer that contain information about the KB/ID changes.

As per Legal Reference: Taxation Act – Section 76A(2)

According to Section 76A(2) of the Taxation Act

"The tax payable under subsection (1) shall be deducted from the amount referred to therein upon—

(a) accrual of the amount to such person; or

(b) payment of the amount to such person whether directly to him or to his account in or outside Malawi; or

(c) remittance of the amount to such person; or

(d) crediting of the amount or of the value thereof in favour of such person…”

The use of "or" in this clause indicates that withholding tax is triggered by the earliest of the listed events — whether it is accrual, payment, remittance, or crediting of the income.

This interpretation aligns with the Malawi Revenue Authority's practice and international tax standards, where withholding obligations are typically triggered at the earliest recognition of income, to avoid deferred taxation.

Key Compliance Requirement

In practical terms:

• If a liability is accrued via an invoice, and no WHT is deducted until later payment, the organization may be seen as non-compliant.
• Therefore, our request to calculate WHT at invoice level is to ensure legal compliance and timely deduction, as required by Section 76A(2)(a).

System Expectation

However, the system currently calculates WHT only at payment, which does not satisfy the requirement for invoice/accrual-based withholding under Malawi law.

Request

We request your assistance in identifying configuration changes or hotfixes that will enable WHT to be triggered at invoice posting (accrual) for the Malawi region.

Ref:

Currently, deferral journals generated via Subscription Billing for procurement scenarios do not support Financial tags, limiting traceability and reporting capabilities. We request that Financial tags be supported in these deferral journals, aligning with their availability in other modules like purchase order invoicing.

in the current implementation of the ER configuration of the electronic invoice import 'Vendor invoice Mapping to destination', when an item cannot be identified by the external item number, the mapping uses an item called 'DEFAULT_ITEM' as a replacement.

We would like very much, that this Item can be replaced by a default procurement category since the options to assign the correct ledger account are way more comfortable using a procurement category instead of an item.

Idea on sales order invoice summary control

Multiple sales orders can be summarized on one invoice using the Summary update for parameter on the Posting invoice form:

In cases where a lot of sales orders are created for a customer which are delivered, this could result in an invoice with a large amount of lines.

Some customers want to avoid having such large invoices, but still want to generate these invoices in batch using the “Late selection” functionality, instead of splitting the sales orders using the query and creating multiple batch jobs manually.

The idea is to add an additional parameter to the Posting invoice form where users can specify the maximum number of invoice lines in case sales orders are grouped on one invoice.

This functionality should keep track of the amount of lines that are grouped under a single sales order header (and one invoice). Once the maximum specified number of lines is reached, the current sales order that was being added should be added in total (to avoid splitting one sales order over two invoices), and the next sales order will become the new sales order header where the next sales orders will be grouped underneath until the specified maximum of lines is reached, or until all selected sales orders are allocated under a sales order header.