2 runs
An ERP allocation is only as current as the headcount it read.
Spreading rent by headcount or IT by users is standard in a finance system. What differs is which basis the run reads, and what a second run does after someone corrects it.
6 rules
The AutoCash rules Oracle Fusion Cloud Receivables documents for a receipt that names no invoice it can match, from oldest invoice first to a pair of invoices that add up to the payment. Read from Oracle's help on 31 October 2026.
Business Central and Oracle Fusion both document automatic cash application, and both match on the reference the customer sends with the money. The useful demonstration is the receipts that arrive without one.
Can the ERP apply customer payments automatically, or do we need a cash application tool? Most pages that answer it are published by companies selling those tools, and their answer is predictable: the ERP holds the invoices and their product does the matching. The ERP vendors' own help pages describe matching too, and they agree on one point. The match is only as good as the reference the customer sends with the money.
In Dynamics 365 Business Central, payments arrive in the Payment Reconciliation Journal from an imported bank file or a bank feed, and the Apply Automatically function proposes a match for each line. It first compares the related party fields on the bank line with the bank account, name or address of customers and vendors that have open entries. It then looks for the transaction text in the document number or external document number of open entries. Last, it compares the statement amount with open amounts. Text matching works only on text longer than four characters.
Each proposal carries a match confidence of High, Medium or Low, set by a table of rules the customer can edit. In Microsoft's standard table, a payment from a recognised party whose amount fits exactly one open entry reaches High with no document number at all. Whatever part of a payment cannot be applied stays in a Difference field, and someone settles it by hand, by mapping recurring text to an account, or by transferring the difference to an account.
Oracle Fusion Cloud Receivables searches a receipt for six kinds of number in a fixed order: transaction number, sales order number, purchase order number, balance forward billing number (lockbox only), shipping reference and contract number. If none matches, it passes the receipt to the AutoCash rule set on the customer's profile, or to the one in system options when the customer has none.
The set holds up to six rules, tried in the order the implementer entered them. Match Payment with Invoice applies a receipt to one item only when the amounts are exactly equal, choosing the earliest due date when several are. Clear the Account and Clear Past Due Invoices apply it only when it equals the customer's whole open or past due balance, and a sixth rule does the same for past due items grouped by payment terms. Apply to the Oldest Invoice First works down from the oldest due date. Combo Rule looks for two items that add up to the receipt exactly: in Oracle's own example a receipt of $572 against five open invoices lands on the ones for $200 and $372. Whatever no rule can place is left unapplied or on account, depending on a setting in the rule set.
Each of those rules is a guess about what the customer meant, ranked by whoever configured it. Oldest first suits a customer that pays its statement. For a customer that pays invoice by invoice and out of date order, it puts the money against an invoice the customer did not pay, and the one it did pay stays open.
Both designs reward a payment that names its invoice and fall back to amounts and dates when it does not. So the size of the job depends more on how your customers pay than on which ERP you choose. Four kinds of receipt decide it.
Bring receipts, not a question. Export a month of real bank lines with the text exactly as your bank sends it, and pick five: a payment quoting one invoice number, one transfer covering several invoices, a short payment, a payment with no reference at all, and a payment from a company other than the customer. Ask the vendor to load matching open invoices, run the automatic application, and show where each receipt landed, on which invoice, at what confidence, and what was left unapplied. Then ask who sets the rule order after go-live, and who may change it.
Before any of that, count your own file. The share of last month's receipts whose bank text carries an invoice number decides whether the ERP's matching is enough, or whether the gap is wide enough to justify a separate cash application tool. A demonstration file is built to match. Yours was not.
Across every text field of the 55 systems Stackmark profiles, no record carries a line on how customer payments are matched to invoices, on remittance advice, or on lockbox. The profiles describe receivables at the level of the module, so this question has to go to each vendor directly, which is what the five receipts are for.
To put the five receipts to every shortlisted vendor in the same words, open the requirements builder, mark financial management as a must have, and describe each receipt in the notes step. The notes travel with the Markdown, CSV and Excel exports, so every vendor runs the same file.
2 runs
Spreading rent by headcount or IT by users is standard in a finance system. What differs is which basis the run reads, and what a second run does after someone corrects it.
0 of 9
Nine of the 55 systems Stackmark profiles name intercompany in their records, and none says how the second entity's entry gets made. Two vendors' own help pages show why that is the question to ask before the demonstration.
1 of 55
Every ERP will report by department, location and product. Where that detail sits decides whether adding a new cut next year is a setup change, a batch job that locks the ledger, or a fresh implementation.