Spreadsheet checks before running Alimony Child Support in South Carolina
5 min read
Published April 15, 2026 • By DocketMath Team
What the checker catches
Run this scenario in DocketMath using the Alimony Child Support calculator.
Before you calculate alimony or child support in South Carolina with DocketMath, run spreadsheet checks that prevent two of the most common failure points: (1) wrong time window and (2) wrong starting assumptions. DocketMath can do the math, but your spreadsheet must be feeding it correctly.
These are the specific checks the “Spreadsheet checker” workflow is designed to catch for US-SC.
1) Missing or inconsistent “start date” logic
Most spreadsheet errors come from quietly inconsistent dates—such as one column using the date of filing, another using the date of separation, and another using a hearing date. Even a one-day mismatch can change:
- the number of months included in the calculation window
- any proration for partial months
- totals that depend on a month count
Checklist
2) Stale assumptions about the statute of limitations (SOL) window
DocketMath’s alimony-child-support calculator uses jurisdiction-aware logic. For South Carolina, the general/default SOL period used by the checker is:
- General SOL Period: 3 years
- General Statute: GS 15-1
Important: No claim-type-specific sub-rule was found for this checker. That means this content uses the general/default 3-year period from GS 15-1, rather than a separate specialized period.
Checklist
Warning: A common spreadsheet pitfall is using a 3-year window in one part of the file while using a different window elsewhere (for example, applying the window only to arrears but not to totals). The checker is designed to force consistency across your period logic.
3) Arrears and payment allocation mismatches
If you track payments (for example, partial payments, lump sums, or payments across different months), allocation logic can drift from what your formulas assume.
Checklist
4) Unit conversion errors (monthly vs. yearly)
Support worksheets often store inputs in yearly format (or as an annualized figure), while calculations expect monthly values.
Checklist
When to run it
Run the checker at multiple points, not only after everything is finished. That’s how you catch “silent” period errors before they cascade.
Run the checker before importing a spreadsheet into the Alimony Child Support workflow. It is especially helpful when you have multiple entries or when a teammate provided the inputs.
1) Immediately after entering dates
As soon as you add the key date fields (start/through dates), do a first pass. This is where SOL-window and month-count issues are easiest to spot.
2) Right before totals or arrears are produced
After you plug in income figures, rates, or payment history, rerun the checker. At this moment, both date logic and period mapping are most likely to affect outputs.
3) After every “small” spreadsheet change
Rerun after any change that could affect timing or month alignment, including:
- changing a date cell
- changing a payment amount
- changing a rate
- changing a rounding setting
Small edits often have outsized effects because month loops and lookback calculations feed many downstream totals.
Quick timing rule
- If a change touches a date, month count, or through date → rerun immediately.
- If a change touches only non-time fields → rerun at least before you rely on arrears/totals output.
Pitfall to watch: Editing a single row in your payment table can break alignment if row order changes or if formulas reference rows by position. The checker workflow is intended to catch these alignment breaks early.
Try the checker
Use DocketMath’s alimony-child-support tool to drive your spreadsheet checks for South Carolina (US-SC) with jurisdiction-aware logic.
Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.
Step-by-step workflow (spreadsheet + DocketMath)
- Open the calculator: /tools/alimony-child-support
- Enter (or confirm) your calculation “through” date and calculation start date.
- Make sure your spreadsheet includes a clearly labeled 3-year lookback window based on GS 15-1 (general/default 3-year period; no claim-type-specific sub-rule found for this checker).
- Add your monthly inputs (or ensure any annual figures are converted consistently into monthly equivalents).
- Map payments into the same monthly buckets the calculator expects.
- Run the spreadsheet checks and compare the results for sanity signals such as:
- total months included
- the computed lookback start date
- arrears totals (if applicable)
How outputs change when inputs change
Use these practical cause-and-effect checks to confirm your spreadsheet and DocketMath are synchronized:
| Input you change | What typically changes in the output | What the checker looks for |
|---|---|---|
| Through date | month count + SOL lookback start | lookback start matches “through date minus 3 years” |
| Start date | eligibility window + period totals | all formulas reference the same start-date cell |
| Payment dates/amounts | arrears allocation + remaining balance | payment table aligns to monthly buckets (no misordered rows) |
| Annual rate stored as yearly | totals change if conversion is wrong | monthly conversion consistency before totals |
| Rounding step | small differences that can add up | rounding applied consistently (monthly vs final) |
If the checker flags inconsistencies, fix the spreadsheet first, then rerun DocketMath so both systems use the same periods and assumptions.
Gentle note: This is a spreadsheet validation guide, not legal advice. If you’re dealing with complex facts, claim types, or unusual payment histories, consider getting professional review of both your dates and your assumptions.