In Excel: use =DSUM(database, field, criteria) — the conditions live in a separate criteria RANGE on the sheet, not inside the formula.
Syntax
Arguments
| Argument | Description | |
|---|---|---|
database | required | The table INCLUDING its header row. |
field | required | Which column to aggregate — a header name in quotes or a column number. |
criteria | required | A separate range whose headers match the table and whose rows hold the conditions. |
Related functions
Grand total: 1,250.50
| Region | Sum |
|---|---|
| West | 125.50 |
| East | 1050 |
| South | 75 |
The same thing in your own sheet
Sum · Excel & Sheets
Need it as an auditable file?
Ships inside the linked template — formula-driven, unlocked, audit-ready.
What this does
The D-functions — DSUM, DGET, DCOUNT, DAVERAGE, DMAX, DMIN — aggregate a table according to conditions written in a separate criteria range rather than in the formula. That is their distinguishing feature and their remaining advantage: a user can change the conditions by typing in cells, without editing a formula, which suits a controlled report handed to non-technical colleagues. Criteria on the same row combine with AND, on different rows with OR — which SUMIFS cannot express at all. The cost is a criteria range that must be maintained and whose headers must match the table exactly. For most work SUMIFS or FILTER is simpler. The same idea underpins a lot of everyday Excel work, so the few minutes spent getting it right here pay back across every sheet you build afterwards. Treat it as a pattern, not a one-off, and it stops being something you look up and starts being something you reach for. Treat “dcount function in excel” as a small repeatable workflow rather than a one-off click you hope to remember next time. Use a small test block before the live file, so any surprise in the affected formula shows up while it is still harmless. When a formula is involved, keep the inputs labelled beside it, reference cells instead of typing values, and apply number formatting only after the result checks out. That turns a calculation you can defend to a CFO or an auditor into a method you can reuse, explain, and defend when the workbook leaves your screen.
A worked example
A table in A1:E500 with headers, and a criteria range in G1:H2 holding "Region" and "West": =DSUM(A1:E500, "Revenue", G1:H2) totals Western revenue and updates the moment someone edits G2. OR logic that SUMIFS cannot do: put "West" and "East" on separate criteria rows. Retrieving a single matching value: =DGET(A1:E500, "Revenue", G1:H2), which errors if more than one row matches. The database functions put the conditions in cells rather than in the formula, which is what makes a report safely editable by someone who should not touch formulas. One habit worth forming early: name the cells that hold your inputs, so the formula reads in plain language instead of a string of cell addresses. A reviewer — or you in three months — can then follow the logic without decoding what B7 and D2 were supposed to mean, which is most of what makes a sheet maintainable.
In Google Sheets
Google Sheets handles this almost identically to Excel. The formula syntax above is the same, and the menu lives under a slightly different label rather than a ribbon tab. Use the platform toggle at the top of the page to switch every keyboard shortcut between Windows and Mac, and expect at most cosmetic differences in naming. The aim was to get you unstuck fast and leave you a little more capable than a copy-paste would. The answer is at the top, the tool proves it, and the detail above shows why it holds — so the next time a colleague asks, you can answer without reaching for search. If you take one thing from this page on “dcount function in excel”, make it the habit rather than the keystrokes: set the problem up with labelled inputs, reference those cells, and let Excel do the recomputing. Bookmark the page for the syntax, but do the example once in a blank sheet and check it against the tool above — five minutes of hands-on practice fixes the method in memory far better than re-reading, and it surfaces the small snags while they are still harmless. After that the technique is genuinely yours: faster than searching for it again, and reliable enough to drop into work that other people depend on.
Common mistakes
- Omitting the header row from the database range, which is required and not optional.
- Criteria headers that do not match the table headers exactly, which silently matches nothing.
- Using DGET where several rows match, which returns
#NUM!— it is strictly single-value.
Frequently asked questions
Why use DSUM instead of SUMIFS?
Because the conditions live in cells a user can edit without touching a formula, and because OR logic across rows is possible, which SUMIFS cannot express.
Why does DGET return #NUM!?
More than one row matches. DGET returns exactly one value or errors.
How do I write OR conditions?
Put them on separate rows of the criteria range. Same row means AND.