How to run Alimony Child Support in DocketMath for Pennsylvania
6 min read
Published April 15, 2026 • By DocketMath Team
Step-by-step
Run this scenario in DocketMath using the Alimony Child Support calculator.
This guide walks you through running Alimony + Child Support calculations in DocketMath for Pennsylvania (US-PA) using jurisdiction-aware rules. It’s written to help you produce consistent numbers for planning and review—not to provide legal advice.
1) Start with the right DocketMath calculator
- Open DocketMath: /tools/alimony-child-support
- Confirm the calculator is set to Pennsylvania (US-PA).
- Select the fields relevant to your situation (typically separate inputs for support components, dates, and any amounts/assumptions your workflow uses).
2) Enter Pennsylvania jurisdiction inputs that drive timing
Pennsylvania has a general statute of limitations (SOL) of 2 years for many support-related enforcement actions under 42 Pa. Cons. Stat. § 5552.
Use this timing in your workflow when you’re modeling whether older amounts may fall outside a general recovery window. DocketMath’s jurisdiction-aware rules can be used alongside your own date inputs to keep your calculations consistent.
Statute reference:
- General SOL period: 2 years
- General statute: 42 Pa. Cons. Stat. § 5552
Note: No claim-type-specific sub-rule was found in the provided jurisdiction data. The 2-year period above should be treated as the general/default period for timing logic unless your workflow incorporates additional claim-type rules you can verify elsewhere.
3) Add date fields carefully (because they control the “window”)
In most support modeling workflows, results depend on some combination of:
- a start date (when obligations began for your model),
- an end date or calculation/as-of date (when you’re measuring through), and
- whether amounts are treated as “within window” vs. “outside window.”
Use consistent date formats and avoid mixing:
- the date the obligation began vs.
- the date an order was entered vs.
- the date you’re doing the calculation “as of.”
If you’re using DocketMath for planning, align your dates with the story you want your outputs to represent.
Practical checklist for dates:
4) Enter financial amounts in the sections that map to the calculator’s structure
Depending on how DocketMath exposes fields, you’ll typically provide:
- income or amount inputs (for the calculation components DocketMath uses),
- any assumptions required by the calculator (for example, support start/end or installment structure), and
- optional modifiers if available in the UI.
If you have both alimony and child support elements, keep them separated as the calculator expects. Mixed entries are a common reason results look “off.”
Input-to-output effect (what changes):
- Changing dates usually changes totals by altering which portion falls within the modeled period/window.
- Changing income/amounts changes the rate or computed support amounts.
- Toggling any scenario options (if the calculator provides them) can shift both timing and magnitude.
5) Review DocketMath outputs and sanity-check the ranges
After running, review each output section for:
- component totals (alimony vs. child support, if shown),
- any per-period figures (weekly/monthly totals), and
- any “within window” vs. “outside window” breakdown (if DocketMath surfaces SOL logic in the output).
Quick sanity checks:
6) Save or copy the results for review workflows
When you’re using DocketMath as part of a larger case workflow (documents, spreadsheets, status reports), copy:
- the final totals,
- the date range reflected, and
- any itemized component breakdown.
This makes later adjustments faster if you correct a date or revise an input.
7) Document your assumptions alongside the calculation
Even without legal advice, you can improve accuracy by keeping a short “assumption log,” such as:
- “Modeled obligation start date as X”
- “Computed through Y”
- “Applied general SOL timing consistent with 42 Pa. Cons. Stat. § 5552 (2 years) using jurisdiction default period”
This helps anyone reviewing the output understand why two runs might differ.
Warning: A common workflow error is using the date the agreement was discussed as the obligation start date. When you change that one date, the “window” logic tied to the 2-year general SOL under 42 Pa. Cons. Stat. § 5552 can move significant amounts in or out of the modeled period.
Common pitfalls
Treating the 2-year SOL as automatically claim-type specific
- With the provided jurisdiction data, the only verified timing rule is the general/default 2-year period under 42 Pa. Cons. Stat. § 5552.
- If you incorporate additional claim-type timing rules, you need separate confirmation.
Mixing dates that represent different legal or practical events
- Obligation start date ≠ order entry date ≠ calculation “as of” date.
- DocketMath will compute based on what you enter, so inconsistent date meaning leads to inconsistent totals.
Entering alimony and child support amounts into the wrong fields
- Many calculators assume separate components.
- If alimony inputs are added where child support inputs are expected (or vice versa), outputs may look structurally wrong even if the numbers “add up.”
Not running a “change one variable” check
- After you enter values, run at least one controlled adjustment:
- Change only the end date by 1 month and rerun, or
- change income by a small amount and rerun.
- If outputs don’t respond logically, revisit the inputs.
Assuming the SOL window should never affect totals
- If your modeled dates extend beyond 2 years, a general timing window can materially change “recoverable” or “included” amounts depending on how the calculator presents timing logic.
- Align your interpretation with the calculator’s output labeling.
Try it
Follow this quick test-run to confirm your setup:
Open DocketMath at /tools/alimony-child-support.
Set Pennsylvania (US-PA) if there’s a jurisdiction selector.
Enter a date range that is within 2 years (for example, start date = Jan 1, 2022; end date = Dec 31, 2023).
Run the calculation and note:
- component totals, and
- any totals described as “within window.”
Now rerun using the same inputs but change only the end date so the range extends beyond 2 years (for example, end date = Jan 31, 2024).
Confirm the outputs behave as expected:
- If timing logic is shown, you should see differences consistent with the 2-year general SOL approach tied to 42 Pa. Cons. Stat. § 5552.
| Test | What you change | What you should observe |
|---|---|---|
| A | End date stays within 2 years | Totals reflect full modeled period (per calculator labels) |
| B | End date extends beyond 2 years | Totals change in a way consistent with general 2-year timing window |
If you want to align your workflow with other DocketMath calculators or cross-check assumptions, you can browse the available tooling at /tools/alimony-child-support.