2 runs
Generate a Sage Intacct dynamic allocation twice for the same period and its help says the first entry is not reversed.
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.
Take the allocation most finance teams set up first: building rent spread across departments by headcount. Any ERP on a mid-market shortlist can produce that journal. The number it posts depends on two things a module list does not show. One is which headcount figure the run read. The other is what happens when someone runs it again after a correction.
An allocation reads a pool, here the rent balance, and a basis, here the headcount by department, then posts the split. The pool is a ledger balance. The basis usually is not. It is a statistical figure that someone has to load every period, and three vendors' own help pages show how differently that is arranged.
In each case the allocation is right for the basis that was in the system at the moment it ran. If the October headcount arrives on the fourth working day and the rent allocation ran on the third, the journal balances, it posts, and every department's share is wrong. Nothing in the ledger flags it, because nothing in the ledger knows the headcount changed.
The correction is where the systems part company, and where a buyer will feel it at month end. Sage Intacct's help is unusually plain about it: if you generate an allocation and then run it again for the same period, the previous allocated entry is not auto-reversed. Unless someone reverses the first journal, the pool is allocated twice. Sage Intacct attaches a snapshot of the allocation's setup and results to the posted entry and lets a user drill into the source and basis amounts it found, so the double is traceable. Preventing it is still the team's job.
Business Central posts an allocation as one line per destination, so a three way rent split becomes three lines. Microsoft notes that this lets you reverse individual lines instead of the whole allocation. Oracle's generation process carries a Post Allocations option. Clear it and the journals wait for a manual post or an AutoPost criteria set, which gives a reviewer a point to check the basis before anything reaches the balances.
Each of these is a reasonable design, and each puts the control in a different place: with whoever loads the statistic, whoever presses generate, or whoever reviews the unposted journal. A buyer should know which one the shortlisted system relies on before signing, because that is the step the close checklist has to carry.
Of the 55 systems Stackmark profiles, none carries a sourced line describing cost allocation. Three records use the word, and all three mean assigning people to projects. The four demonstration questions on the financial management module page cover shared charts of accounts, intercompany elimination, the close and reopened periods; none asks about allocations. Stackmark's own glossary calls allocation usually the least documented step in the close, and on this evidence the profiles document it no better. A buyer cannot tell from them how a shortlisted system handles it, which is a reason to test it rather than ask.
Give each vendor one of your real allocations with real numbers: last month's rent pool and the headcount by department. Ask them to load the headcount, run the allocation, then change one department's headcount and run it again for the same period, with a user from your finance team watching the screen.
Then look at the ledger, not the allocation screen. Is there one journal or two? If two, did the system warn anyone? Which period's headcount did each run read, and is that shown on the entry an auditor would open? Can a reviewer see the split before it posts? A system that reverses or blocks the first run has made the correction safe. A system that posts a second journal beside the first has made it the checklist's job, which is workable if the checklist knows.
To give every shortlisted vendor the same scenario in the same words, open the requirements builder, mark financial management as a must have, and paste the scenario into the notes step. It travels with the Markdown, CSV and Excel exports, so each vendor runs the same allocation twice.
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.
6 rules
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.