These two terms get used interchangeably often enough that I've had otherwise-experienced developers on a call insist they mean the same thing, and then get confused when I explain that Acumatica has one clear answer for one of them and a genuinely more nuanced answer for the other. Tiers are physical - where code actually runs, on which machine. Layers are logical - how code is organized within a single running process. Acumatica has a definite tiering story and a less obvious, but real, layering story underneath it.
Tiers: where the bytes actually execute
Physically, a standard Acumatica deployment is two or three tiers depending on scale: a web tier (IIS hosting the ASP.NET application, handling HTTP requests and rendering), a database tier (SQL Server holding all persisted data), and optionally a separate application server tier for larger deployments, where the actual PXGraph execution is offloaded from the web tier's worker processes onto dedicated app servers, communicating back to the web tier over a defined protocol. SaaS instances hide this behind Acumatica's own hosting, but the same physical shape exists underneath, usually with more aggressive horizontal scaling on the web tier and app server tier than most on-prem deployments bother configuring.
[ Browser / Mobile client ]
| HTTPS
v
[ Web tier — IIS, ASP.NET, w3wp.exe ]
| (optional: offload to app server tier under load)
v
[ Application server tier — PXGraph execution, optional ]
| SQL / TDS
v
[ Database tier — SQL Server ]
This is a fairly ordinary n-tier web application shape. What trips people up is assuming tier boundaries imply layer boundaries - that because the web tier and app server tier are physically separate, the code running on each must be cleanly separated by responsibility too. It isn't, necessarily; the same graph and DAC assemblies get loaded on whichever tier ends up executing them, and Acumatica decides that placement, not your customization code.
Layers: the logical organization within the process
Within a single running Acumatica process, the logical layering is the DAC/graph/screen triad discussed constantly on this blog, and it doesn't map cleanly onto classic presentation/business/data-access layering from older enterprise architecture guides. The DAC is simultaneously your data access layer (it maps to a table) and part of your presentation layer (its attributes drive UI behavior) and part of your business layer (its attributes enforce validation). This blurring is deliberate - Acumatica's attribute-driven model trades classic separation-of-concerns purity for the ability to define a field's storage, validation, defaulting, and display behavior in exactly one place, which is genuinely valuable for maintainability even though it doesn't fit the textbook n-layer diagram.
The graph is your closest analogue to a business logic / application layer, and it's worth keeping business rules there rather than smearing them across DAC attributes when the rule is genuinely about workflow rather than about the field's own validity. A field-level rule ("this must be a positive number") belongs on the DAC. A workflow rule ("this can only go on hold if the customer has an active support contract") belongs in the graph's event handlers, because it requires knowledge the DAC alone shouldn't have to hold.
Why this distinction actually matters when you're building something
I bring this up with new developers specifically because conflating tiers and layers leads to two different but equally common mistakes. Mistake one: assuming that because the app server tier is physically separate, you can put tier-specific logic there deliberately (you generally can't - Acumatica decides where a graph executes, and coding against a specific tier's process is not a supported pattern). Mistake two: assuming that because the DAC/graph/screen triad isn't cleanly n-layered in the textbook sense, there's no discipline to apply at all, and business logic ends up scattered randomly between DAC attributes, graph event handlers, and even client-side script includes with no consistent rule for where new logic goes. The actual discipline: field-level concerns to the DAC and its attributes, workflow and cross-field concerns to the graph, and don't try to impose tier-awareness on code that Acumatica's own deployment topology controls, not you.
What this means for scaling decisions
Because tiers are about physical placement and layers are not, scaling an Acumatica deployment is a tiering exercise, not a layering one. Adding app server tier capacity helps when PXGraph execution (business logic, report generation, heavy BQL queries) is the bottleneck. Adding web tier capacity helps when request handling and rendering is the bottleneck. No amount of reorganizing your customization's internal "layers" changes which physical tier absorbs load under a given workload - that's a topology decision made in IIS and app server configuration, covered in more detail in the VM sizing and AWS/Azure/on-prem material on this site.
Wrapping up
Tiers are physical, layers are logical, and Acumatica has a clean, conventional answer for tiers (web, optional app server, database) and a deliberately blurred answer for layers, because the DAC/graph/screen triad trades textbook separation-of-concerns for single-source-of-truth field definitions. Don't try to impose tier-specific logic Acumatica doesn't let you control, and don't mistake the platform's blurred layering for an excuse to skip discipline about where field-level versus workflow-level logic belongs.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.