Spreadsheet checks before running Alimony Child Support in Pennsylvania
6 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
DocketMath’s alimony-child-support tool for Pennsylvania (US-PA) includes spreadsheet checks designed to catch common spreadsheet issues before you rely on any totals for alimony, child support, or both. Think of it like “pre-flight” validation: it helps ensure your sheet’s dates, frequencies, and inputs are consistent so the calculator doesn’t produce numbers based on broken assumptions.
Below are the most practical checks the tool supports in a Pennsylvania workflow—especially when your sheet includes payment timelines, enforcement dates, or any “lookback” concept.
1) Date math that silently breaks
Spreadsheet errors involving dates often don’t crash your sheet—they just produce wrong inclusion/exclusion of payments.
Typical causes include:
- Mixing date formats (for example,
MM/DD/YYYYin one column andYYYY-MM-DDin another). - Off-by-one mistakes where the “scenario start date” or “first payment date” shifts by a day or a month.
- Using text dates that sort alphabetically rather than chronologically.
A checker should flag:
- Rows where a payment date is blank.
- Rows where the payment date falls outside the modeling window you intended (based on your anchor/coverage dates).
- Any inconsistency between your sheet’s scenario start and the first payment date.
2) Lookback windows tied to Pennsylvania’s general limitations period
For US-PA, your jurisdiction data provides a general statute of limitations (SOL) period of 2 years under 42 Pa. Cons. Stat. § 5552. Use this as the default baseline when your spreadsheet includes a lookback window.
Jurisdiction data (US-PA):
- General SOL Period: 2 years
- General Statute: 42 Pa. Cons. Stat. § 5552
Important clarity (from the provided jurisdiction note):
No claim-type-specific sub-rule was found in the provided jurisdiction data. So this checker reflects the general/default 2-year period from § 5552, rather than applying a different limitations period based on claim type.
Practical spreadsheet checks tied to this:
- If your sheet uses an enforcement date or similar anchor to define a “covered” or “in-scope” period, verify the length aligns with a 2-year default window.
- If you filter payments “within the last 24 months,” confirm your date range truly spans 24 months from the anchor date your sheet uses.
How output changes when this is wrong:
If your lookback window is accidentally 18 months (or 30 months), your totals may look plausible, but they will be based on the wrong set of payments—changing sums, averages, and period totals.
3) Amount fields that don’t align with frequency
Even if your date logic is correct, spreadsheets frequently misstate timing by mixing monthly and non-monthly amounts.
Examples:
- One tab uses monthly amounts; another uses weekly or biweekly amounts.
- A conversion step (weekly → monthly, monthly → annual) is applied inconsistently or only on some rows.
A checker should validate:
- Conversion logic is consistent across all rows (not just totals).
- Totals reconcile to the schedule you intended (for example, monthly totals should reflect a monthly schedule, not an annualized schedule).
How output changes when frequency is wrong:
Totals can be off by a factor related to the frequency assumption—sometimes without any obvious error indicator—especially when the spreadsheet displays “rounded” numbers.
4) Incomplete or mismatched inputs
Spreadsheet-driven calculations depend on consistent inputs. Missing or contradictory fields can create misleading outputs.
Common input problems:
- Blank income rows or blank adjustment fields that your sheet expects to be numeric.
- A “child” vs. “spouse” toggle (or similar selection) applied incorrectly—so a column is effectively used for the wrong purpose.
- Negative values entered inconsistently (for example, using parentheses in one place but minus signs in another) without a consistent sign convention.
A checker should catch:
- Missing critical inputs (especially anything that feeds the schedule or adjustments).
- Structural mismatches (columns used for the wrong role, or toggles that cause fields to be ignored/duplicated).
5) Scenario contamination across tabs or versions
It’s easy to copy a spreadsheet tab to create “Scenario B,” then forget to update the values that control which payments are included.
Common places scenario updates are missed:
- The scenario start date
- The anchor date (the “from/through” dates that drive the 2-year default lookback)
- The payment frequency assumption (monthly vs. weekly/biweekly)
A checker should help you confirm:
- Scenario A vs. Scenario B inputs (especially dates and frequency) are aligned with what you think you’re calculating.
- Changes that impact totals are actually intentional.
When to run it
Run DocketMath’s spreadsheet checks before you trust the output numbers. Here are the best “timing” points in the workflow:
Before the first calculator run
- Validate date fields, start/end logic, and payment frequency assumptions first.
Before you lock a final spreadsheet version
- Re-run checks after any edits—even small ones—because date range or conversion issues can quietly shift totals.
After changing the anchor date for your lookback
- Since the general/default SOL period is 2 years under 42 Pa. Cons. Stat. § 5552, changing your “from” or “through” date can change which rows qualify in a default 24-month window.
After switching between monthly and annual representations
- Frequency mismatches are among the easiest errors to introduce and often compound across 12–24 months.
Quick pre-run checklist (spreadsheet-level):
Try the checker
You can test the flow using DocketMath’s alimony-child-support tool. Enter your scenario inputs, then use the checker output to validate your spreadsheet structure before relying on calculated figures.
Primary CTA: Run the Alimony Child Support checker
As you run it, pay attention to how output changes when you adjust inputs:
- Change the anchor date: payments that fall outside (or inside) the default 2-year window tied to 42 Pa. Cons. Stat. § 5552 may drop out (or return), changing aggregate totals.
- Change payment frequency: monthly vs. weekly/biweekly assumptions alter the schedule and therefore totals—even when the “monthly equivalent” isn’t explicitly shown.
- Edit start/end dates: if your sheet includes a first payment month or coverage start, schedule length changes can shift totals.
Gentle reminder: A limitations period can significantly affect which payments are treated as “in scope” for spreadsheet summaries. This content uses the general/default 2-year period under § 5552 based on the provided jurisdiction data and does not apply any claim-type-specific rule (because none was identified in the provided dataset).
