Getting paid should be the satisfying part.
The customer has the invoice. The money arrives. Accounts receivable closes the balance and everybody moves on.
Anyone running a busy finance operation on Microsoft Dynamics 365 knows the real version. The money arrives first. The explanation arrives later, arrives incomplete or never arrives at all. Finance then has to work out which customer paid, which invoice they meant and why the amount in the bank is not the amount in Dynamics.
Dynamics is very good at accounting for money it can identify. It cannot manufacture payment context that disappeared before the transaction reached the ERP.
The customer used the wrong invoice number
Invoice references look beautifully controlled inside an ERP. Outside it, they become free text.
A customer types 10584 instead of 10548. They use the sales-order number because that is what their approval email displayed. They enter their own supplier code, an old invoice number or simply “payment”. Another customer pays five invoices in one transfer and can fit only one reference into the bank field.
The bank has received the money correctly. Dynamics has an open invoice for the correct amount. The automatic match still fails because the one piece of information intended to connect them is wrong.
At low volume, somebody recognises the amount or customer name. At high volume, the same process becomes a queue of educated guesses.
A BSB and account transfer tells you where the money landed
A standard transfer to a BSB and account number is excellent at moving value. Its usefulness as a receivables message is limited.
The bank feed may show an amount, date, payer description and whatever reference survived the journey. It usually does not deliver the accounts-receivable explanation Dynamics wants: customer account, invoice number, business unit, payment purpose and allocation instructions.
Two customers can pay the same amount on the same day. A parent company may pay on behalf of a subsidiary. A payment provider or trust account may appear as the sender instead of the customer. Once the credit reaches a shared bank account, finance is trying to infer business meaning from a banking record.
That is not really automation. It is detective work with an import file.
Merchant settlements are not sales receipts
Card payments create a different mismatch.
A customer pays a $10,000 invoice. The acquirer deducts merchant fees and deposits $9,820. Dynamics expects $10,000 against the invoice. The bank shows $9,820. Both numbers are correct, but they describe different events.
The missing $180 is not an underpayment. It is an expense. Depending on the provider, the settlement may also combine dozens or thousands of card transactions, refunds, chargebacks and adjustments into one net deposit.
A clean journal needs to separate the gross receipts from merchant fees and any other movements:
Customer receipts: $10,000
Merchant-fee expense: $180
Cash received: $9,820
Trying to match the bank deposit directly to the invoice guarantees an exception. Finance needs the settlement detail between the checkout and the bank.
PayID fixed the speed and exposed the volume
PayID and Osko make it easy for customers to send money in near real time. For the recipient, that can mean every customer payment appears as its own line on the bank statement.
That is manageable at twenty payments. At twenty thousand, it is a data-ingestion problem.
The finance team does not need a prettier bank statement with thousands of rows. It needs those payment events captured, identified, classified and posted into Dynamics in a controlled form. It needs the detail available for audit without forcing a person to treat every deposit as a separate research project.
Real-time money without real-time context simply creates an unmatched-payment queue faster.
Managed PayID changes the shape of the problem
This is where Managed PayID earns its name.
Instead of relying on a customer to type the perfect invoice reference into a generic bank transfer, Managed PayID gives the receiving process a controlled identity and captures the payment event at source. The system can retain the payer and payment context needed to classify the receipt before it becomes an anonymous line in a bank feed.
RTSP sits between Australian payment rails and Microsoft Dynamics 365. It captures events from Osko and NPP, BECS and merchant channels, enriches them with the context the ERP needs, then posts balanced, audit-ready journals into Dynamics 365.
For high-volume PayID receipts, that means consolidating and classifying thousands of inbound credits through a controlled posting model. Finance keeps the transaction-level evidence, while Dynamics receives accounting entries designed for the ledger rather than a wall of unexplained bank lines.
For merchant settlements, the same principle applies. Gross transactions, fees, refunds and net cash need to be reconciled as related parts of one settlement. The answer is not to force $9,820 to look like a $10,000 invoice payment. It is to post the $10,000 receipt and the $180 cost correctly.
What good looks like in Dynamics 365
A good receiving process should be boring.
The payment arrives. The customer and purpose are identified. The invoice is closed using the gross amount. Fees go to the right expense account. The cash journal balances to the bank. Supporting evidence is attached. Genuine exceptions go to a human with enough information to resolve them.
That last point matters. Automation should reduce the exception queue, not hide it. A payment that cannot be matched confidently should remain visible, with its original evidence intact and an audit trail showing what happened next.
The Payment Nerd view
Most receivables problems are described as reconciliation problems. By the time reconciliation starts, the real mistake has often happened already: the payment was allowed to arrive without enough identity or context.
Dynamics 365 cannot fix a wrong invoice number, expand a thin bank description or guess the gross value behind a net merchant settlement with certainty. It can only account for the information it receives.
Managed PayID moves the control closer to the payment. RTSP then carries that context through to Dynamics in a form finance can use.
The point is not to make bank statements disappear. It is to stop asking the bank statement to do the job of a settlement layer.
Learn more: RTSP — the settlement layer for Microsoft Dynamics 365.