Acumatica licenses by concurrent usage, not by named user — a distinction that trips up almost every team the first time an integration or a batch job starts eating sessions nobody accounted for. Understanding what actually counts as a session, and how headroom is measured, is the difference between sizing your license correctly and getting a surprise lockout during month-end close.
What actually consumes a concurrent session
Every logged-in user with an active session counts against your license's concurrent user limit, for as long as that session is alive — which is not the same as "actively clicking." A user who logs in at 8am and leaves the browser tab open all day without ever hitting an idle timeout holds a session the entire time, even during lunch. Integration users (REST/SOAP API connections) count too, and unlike a human's browser session, a poorly written integration that opens a new login per API call without logging out can leak sessions far faster than any human would.
Session timeout is the lever that actually matters
The single biggest factor in how many concurrent sessions your real user count consumes is the idle session timeout, configured in the site's web.config or through Acumatica's session settings. A short timeout (say, 20-30 minutes) reclaims sessions from people who stepped away, while a long or disabled timeout means your concurrency ceiling is effectively "everyone who logged in today and forgot to log out," which is a much bigger number than "everyone actively working right now."
An integration that authenticates per request and never calls the logout endpoint accumulates orphaned sessions until they eventually time out — during that window they consume real concurrency slots. Any custom integration built against Acumatica's REST or SOAP API should explicitly log out after each unit of work, or better, maintain one long-lived authenticated session reused across calls rather than opening a new one per request.
Monitoring headroom before you hit the wall
Acumatica's System Monitor / license utilization views (accessible to administrators) show current active sessions against the licensed concurrent limit in something close to real time. The pattern worth building is a scheduled check — even a simple Generic Inquiry or a small script hitting the login sessions data — that alerts when utilization crosses a threshold (say, 80% of licensed concurrency) well before month-end close pushes everyone into the system simultaneously and someone gets locked out mid-posting.
What actually happens when you hit the ceiling
When concurrent sessions reach the licensed limit, the next login attempt is rejected outright rather than queued — the user sees a licensing error, not a wait. This is the scenario that makes concurrency planning matter operationally: it tends to happen at the worst possible time, when the whole finance team is trying to close the books simultaneously and every session that should have timed out hours ago is still counted as active.
Sizing the license to usage patterns, not headcount
Because it's concurrent rather than named-user licensing, the right sizing question is not "how many people have accounts" but "what's the realistic peak overlap" — a company with 200 total users where finance, sales, and warehouse rarely log in simultaneously needs meaningfully fewer concurrent licenses than the headcount suggests. Look at actual peak concurrent session data (available from the same monitoring views) across a representative period including month-end, not a guess, before negotiating license count.
Reducing pressure without buying more seats
Before assuming you need to buy more concurrent licenses, check the cheaper fixes first: tighten the idle timeout, audit integration users for sessions that never log out, and confirm no service account or scheduled process is holding a session open unnecessarily around the clock. It's common to reclaim 10-20% of apparent concurrency just by fixing timeout and integration hygiene, which is a lot cheaper than the next license tier.
Wrapping up
Concurrency in Acumatica is governed almost entirely by session lifetime, not by how many people are actually working — a short idle timeout and disciplined integration login/logout behavior recover more headroom than most teams realize. Monitor real peak usage before the license renewal conversation, and you'll size correctly instead of guessing from headcount.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.