Skip to main content

Accounting Academy

MODULE 1: Fundamentals

MODULE 2: Calculations

MODULE 3: Batch Partitioning & LCA

MODULE 4: Mass Balance with Ledgers

MODULE 5: Integration Testing

MODULE 6: Advanced Patterns & Production

Documentation Index

Fetch the complete documentation index at: https://docs.mangrovesystems.com/llms.txt

Use this file to discover all available pages before exploring further.

What you’ll learn in this lesson:
  • Diagnose slug mismatch errors between event types and models
  • Fix timing and sequencing issues in batch generation
  • Resolve data type mismatches and unit conversion errors
  • Troubleshoot calculation dependency problems
Even with careful configuration, integration issues arise when connecting the pieces of a production accounting project. This lesson covers the most common pitfalls and how to fix them.

​
Pitfall 1: Slug mismatches

The most common integration error. It happens when the datapoint slug in the event type doesn’t match what the model expects.

Symptoms

  • Model node produces no output (empty/null value)
  • Batch generation validation says “missing required datapoint”
  • Some batches have outputs, others don’t (inconsistent slug across events)
  1. Open the Model Editor and note the data_point_type slug for each input node
  2. Open Data Inputs > Input Settings and check the actual slug for each datapoint in the event type
  3. Compare — they must be exactly identical (case-sensitive, hyphens vs. underscores)
Update either the model node’s data_point_type or the event type’s datapoint slug so they match. If you change the event type slug, existing events may need to be updated.
Establish a slug naming convention early (e.g., always use hyphens, always lowercase) and stick to it. This prevents mismatches before they happen.

​
Pitfall 2: Timing and sequencing issues

Events must fall within the accounting period for their data to be included in a batch.

Symptoms

  • Batch shows zero output even though events exist
  • Some events are included in the batch but others aren’t
  • Validation passes but output is unexpectedly low
  1. Check the date range of your events vs. the batch accounting period
  2. Verify the event’s start_time and end_time — do they overlap with the batch period?
  3. Look at the show time option when generating batches — time-of-day can exclude events at period boundaries
Per the Generate Batchesdocumentation, events must fall within the selected accounting period.
  • Adjust event date ranges to fall within the accounting period
  • Use the show time option to include events at period boundaries
  • For monthly data (like energy consumption), ensure the event date range covers the full month
A common mistake: creating an energy consumption event with a single date instead of a date range. If the event covers January 1-31, set both start_time and end_time accordingly.

​
Pitfall 3: Data type mismatches

A numeric datapoint stored as text, or a percentage stored as a decimal when the model expects a whole number.

Symptoms

  • Calculation produces wildly incorrect values (e.g., 8000% instead of 80%)
  • Type errors in the model console
  • Values appear correct in events but produce wrong model outputs
  1. Check the value type configured for each datapoint in the event type (number, text, date)
  2. Check how the model interprets the value — does it expect a fraction (0.80) or a percentage (80)?
  3. Look at actual event values — are they stored as the correct type?
  • If the model expects a fraction but events store percentages, add a division-by-100 node in the model
  • Ensure all numeric datapoints are configured as number type (not text)
  • Add explicit unit conversion nodes rather than assuming units match
The most common data type issue is percentages: an event stores 80 (meaning 80%) but the model multiplies directly by 80 instead of 0.80. Always add an explicit division by 100 for percentage datapoints.

​
Pitfall 4: Calculation dependency problems

A model node that depends on another node’s output but the dependency isn’t correctly wired.

Symptoms

  • Model validation error about circular dependencies
  • Intermediate node shows correct value but downstream node doesn’t use it
  • Output is always the same regardless of input changes
  1. In the Model Editor, trace the node tree from output back to inputs
  2. Verify each calculated node’s children are correctly listed
  3. Check that intermediate nodes are referenced by name (not recreated)
  4. Look for nodes with no children or orphaned nodes not connected to the tree
  • Ensure each calculated node explicitly lists its children in the YAML
  • Remove any duplicate nodes — each calculation should exist once and be referenced by downstream nodes
  • If you see circular dependency errors, restructure the tree so data flows in one direction
Draw the node tree on paper first. It should be a directed acyclic graph (DAG) — every path goes from inputs to outputs, never backwards.

​
Pitfall 5: Missing aggregation across events

When a model expects aggregated values (e.g., total kWh for the month) but receives individual event values.
  • Emission calculations use only one energy event instead of the sum
  • Batch output changes depending on which event is processed first
  • Total emissions don’t match the sum of all energy events
Check whether the model node has the should_aggregate flag set. Without it, the node may only pick up a single event’s value rather than summing across all events of that type in the period.
Set should_aggregate: true on model input nodes that need to sum values across multiple events (e.g., total electricity for the month). See the model referencefor aggregation options.

​
Debugging workflow

When something goes wrong, follow this systematic approach:

​
Check your understanding

Slug mismatches between event type datapoints and model nodes. Diagnose by comparing the data_point_type in the Model Editor against the actual slug in Data Inputs > Input Settings. They must be exactly identical — case-sensitive, same delimiters (hyphens vs. underscores).
Add an explicit division-by-100 intermediate node in the model. If the event stores 80 (meaning 80%), the model should include a node that divides by 100 to get 0.80 before using it in multiplication. Never assume input units — make conversions explicit and visible.
You’re ready to put all of this into practice in the Module 5 Exercise: End-to-End Integration Testing.