Spreadsheet checks before running Alimony Child Support in Indiana

What the checker catches

Run this scenario in DocketMath using the Alimony Child Support calculator.

Before you compute Indiana alimony or child support using DocketMath’s alimony-child-support calculator, run a quick “spreadsheet sanity” pass. DocketMath’s calculator expects inputs that match the way support obligations are modeled in Indiana cases. Spreadsheet errors are one of the fastest ways to end up with numbers that are mathematically “clean” but not usable for decision-making.

Below is a jurisdiction-aware spreadsheet checker for Indiana (US-IN), focusing on the general statute of limitations (SOL) framework for recovery actions:

1) Date-driven mismatch (SOL + event dates)

A common spreadsheet failure is using the wrong date column (for example, date filed vs. date of separation) or mixing date conventions (e.g., “through date” included in one place but excluded in another). If your sheet compares obligations to the lookback window incorrectly, outputs may not align with the intended 5-year limitations framework.

What to verify in your inputs:

• Obligation start date (whatever trigger you’re modeling—often based on a separation/family-law event or filing, depending on your sheet)
• Payment history dates (first payment date, last payment date)
• Your lookback start / arrears cutoff date (the date you compute coverage from)

The checker should flag if your “months included” (or “weeks included”) logic implies a coverage period that doesn’t reflect a 5-year window anchored to your sheet’s intended timeframe.

2) Sign and direction errors

Even experienced users sometimes invert amounts in spreadsheets. The checker should look for patterns that indicate direction mistakes, such as:

• Weekly vs. monthly amounts entered with the wrong sign (e.g., expenses treated like income)
• “Arrears” entered as a positive “credit” rather than an amount that represents what is owed
• Order-of-operations issues (adding income and subtracting expenses in the wrong columns)

Practical flags to add:

• If an income line is entered as $40,000 where you expected something closer to $4,000 (order-of-magnitude error), treat it as a likely unit or decimal problem.
• If deductions or adjustments routinely create a negative net income that your model shouldn’t produce, require a manual review before trusting totals.

3) Unit consistency problems (weekly/monthly/annual)

Indiana-focused support modeling often hinges on converting sources into a consistent cadence. Your checker should ensure:

• Wages and benefits are converted to a consistent basis before running calculations
• Taxes are treated consistently (either estimated consistently across months, or excluded entirely if your model is designed to ignore them)

If one input is weekly while another is monthly, the DocketMath output can look “precise” but be off by a factor of roughly 4× (weekly → monthly) or 12× (annual → monthly).

What the checker should verify:

• Every wage/benefit row shares the same unit basis (or is explicitly converted to match)
• Conversion factors are applied once—not twice—and are applied to the correct columns

4) Column drift and stale formulas

Spreadsheet drift happens when:

• A new row is inserted but a formula range doesn’t expand
• A formula is copied across columns with different headers/meaning
• A referenced cell was renamed or moved, but totals still “work” because something else happens to sum correctly

Checker steps that catch this:

• Confirm each formula references the correct labeled column (not just “column D” by position)
• Confirm totals are computed from the rows you intend (especially when you add or remove income/expense lines)
• Spot-check line-item outputs: if one category behaves differently than its neighbors, you likely have a reference issue

5) Output interpretation mismatches (same math, different meaning)

A checker should also validate the interpretation layer. For example, your spreadsheet might:

• produce monthly obligations
• estimate a total arrears number
• report a lookback-trimmed arrears range

If DocketMath outputs are interpreted using a different timeframe or unit cadence than your sheet assumes, your totals can diverge without any obvious arithmetic error.

How to make this practical: Add a small “read me” / “assumptions” section to your spreadsheet that clearly states:

• the modeling window (e.g., “from [lookback start] through [through date]”)
• the unit basis (monthly vs. annual)
• any rounding rules (monthly rounding, partial months, etc.)

Then the checker compares that stated window against what your formulas are actually doing.

When to run it

Run the checker at three points—before you trust any number.

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.

Step 1: Before you enter inputs into DocketMath

• Validate your date columns and confirm you’re using the same “through date” convention throughout the sheet
• Confirm income items are normalized to a consistent unit basis (weekly/monthly/annual as appropriate)
• Sanity-check that your intended lookback start date aligns with the default 5-year rule for Indiana’s general SOL (per Ind. Code § 35-41-4-2)

Step 2: Right after DocketMath generates the estimate

Use the checker to compare:

• your spreadsheet totals vs. DocketMath-derived figures
• whether you applied the same lookback window and cadence (e.g., monthly obligations summed over the same coverage window)

If the numbers don’t align, pause and use the checker to isolate whether the issue is:

• a date window mismatch (coverage period)
• a unit/cadence mismatch (weekly vs. monthly)
• a formula/reference mismatch (column drift)

Step 3: After every revision to income or dates

Treat changes like version control:

• If you update income amounts, rerun the checker and re-check unit conversions
• If you update dates (especially lookback start or through date), rerun the SOL-window logic using the default 5-year period from Ind. Code § 35-41-4-2

Quick checklist (copy/paste)

Try the checker

Start with the DocketMath alimony-child-support tool and build a lightweight spreadsheet around it. Then run the checker logic above to verify that your sheet’s dates, units, and formula mappings align with your intended Indiana (US-IN) modeling approach.

1. Open the calculator: /tools/alimony-child-support
2. Enter your normalized inputs (use one consistent unit basis for wages and benefits)
3. Generate results
4. Run spreadsheet checks:

   • confirm your dates create a consistent modeled timeframe (aligned to the intended lookback window)
   • confirm totals use the same unit basis as the DocketMath output
   • verify that arrears lookback logic reflects the default 5-year period under Ind. Code § 35-41-4-2

Inputs → outputs map (what your checker should confirm):

Pitfall to watch: If your sheet autofills formulas down after you add an income line, totals may still “look right,” while specific line items are mis-referenced. A reference-focused checker prevents this from slipping through.

If you’d like to avoid accidental mismatches, rerun the checker immediately after your first draft and then only when you change dates, income amounts, or conversion factors.

Gentle note: This content is for planning and data quality checks, not legal advice. If you need advice for a specific case, consider consulting a licensed Indiana attorney or other qualified professional.

Related reading

• Alimony & Child Support Estimator Guide for Alabama
• Alimony & Child Support Estimator Guide for Arizona
• Alimony & Child Support Estimator Guide for Colorado