Overview
The Compare Attribute Values filter validates mathematical calculations by comparing the result of a computed operation against a stored result value. This filter performs arithmetic operations (addition, subtraction, multiplication, division) on two attributes and compares the calculated result with a third attribute containing the expected result. It can filter cases based on whether the calculation matches, differs from, or produces null results compared to the stored values.
The filter supports both case-level and event-level filtering depending on the source of the attributes. It includes tolerance handling for floating-point precision issues through a configurable threshold, making it ideal for data quality validation and anomaly detection in business processes.
Common Uses
- Data Quality Validation: Verify that calculated totals match stored totals in financial data, identifying potential data entry errors or system calculation issues.
- Invoice Verification: Check that line item amounts (quantity * price) match the stored total amount, flagging invoices with calculation discrepancies.
- Reconciliation Analysis: Find cases where expected calculations don't match actual values, such as tax calculations, discount applications, or currency conversions.
- Fraud Detection: Identify suspicious transactions where calculated values don't align with recorded values, potentially indicating manual manipulation or system errors.
- Process Integrity Checks: Ensure that derived values in your process data are mathematically consistent with their source values.
- System Migration Validation: Verify data integrity after system migrations by checking that calculated fields remained consistent with their source values.
Settings
First Operand: The name of the first attribute used in the mathematical operation. This must contain numeric data (integer or decimal) and must be from the same source (case or event) as the other operand and result attributes.
Operation Type: Specifies the mathematical operation to perform between the first and second operands. Available options:
- Add: Addition operation (First Operand + Second Operand)
- Subtract: Subtraction operation (First Operand - Second Operand)
- Multiply: Multiplication operation (First Operand * Second Operand)
- Divide: Division operation (First Operand / Second Operand). Automatically handles division by zero by treating it as a null result.
Second Operand: The name of the second attribute used in the mathematical operation. This must contain numeric data and must be from the same source as the first operand and result attribute.
Result Attribute: The name of the attribute containing the expected result value to compare against the calculated operation result. This must contain numeric data and must be from the same source as the operand attributes.
Keep Records: Determines which records to keep based on the comparison result:
- Same: Keeps records where the calculated result matches the stored result (within the specified threshold)
- Different: Keeps records where the calculated result differs from the stored result
- Null: Keeps records where the calculation produces a null result (typically due to missing values or division by zero)
Tolerance Threshold: Sets the tolerance threshold for treating small differences as zero due to floating-point precision issues. If the absolute difference between calculated and expected results is less than this threshold, the difference is considered zero (matching). Default is 0.01. Set to 0.0 for exact comparison with no tolerance.
Examples
Example 1: Finding Invoice Calculation Errors
Scenario: You want to identify invoices where the line item total (Quantity * Unit Price) doesn't match the stored Line Total value, indicating potential data entry or calculation errors.
Settings:
- First Operand: "Quantity"
- Operation Type: Multiply
- Second Operand: "Unit Price"
- Result Attribute: "Line Total"
- Keep Records: Different
- Tolerance Threshold: 0.01
Result: The filter returns cases where the calculated value (Quantity * Unit Price) differs from the stored Line Total by more than 0.01.
Insights: These cases may represent data entry errors, rounding inconsistencies, system calculation bugs, or potentially fraudulent manual adjustments. Cases should be reviewed for correction.
Example 2: Validating Discount Calculations
Scenario: You need to verify that the final price equals the original price minus the discount amount, helping identify pricing errors or incorrect discount applications.
Settings:
- First Operand: "Original Price"
- Operation Type: Subtract
- Second Operand: "Discount Amount"
- Result Attribute: "Final Price"
- Keep Records: Different
- Tolerance Threshold: 0.01
Result: The filter selects cases where (Original Price - Discount Amount) does not match the stored Final Price.
Insights: Discrepancies could indicate incorrectly applied discounts, data entry mistakes, or pricing policy violations that require investigation.
Example 3: Detecting Tax Calculation Issues
Scenario: Identify orders where the calculated tax amount (Subtotal * Tax Rate) doesn't match the stored tax value, which could indicate tax calculation errors or rate changes.
Settings:
- First Operand: "Subtotal"
- Operation Type: Multiply
- Second Operand: "Tax Rate"
- Result Attribute: "Tax Amount"
- Keep Records: Different
- Tolerance Threshold: 0.001
Result: The filter returns cases where the calculated tax differs from the stored tax amount.
Insights: These cases may require tax recalculation, refunds, or corrections to ensure compliance with tax regulations.
Example 4: Finding Cases with Missing Calculation Data
Scenario: You want to identify cases where calculations cannot be performed due to missing values, helping detect incomplete data entry or system integration issues.
Settings:
- First Operand: "Amount"
- Operation Type: Divide
- Second Operand: "Quantity"
- Result Attribute: "Unit Price"
- Keep Records: Null
- Tolerance Threshold: 0.01
Result: The filter selects cases where any of the three values (Amount, Quantity, or Unit Price) are null, or where Quantity is zero (division by zero).
Insights: These cases indicate data quality issues that need to be addressed, such as missing required fields or incomplete transactions.
Example 5: Verifying Balance Calculations
Scenario: Ensure that the opening balance plus the transaction amount equals the closing balance in financial accounts, with exact precision required.
Settings:
- First Operand: "Opening Balance"
- Operation Type: Add
- Second Operand: "Transaction Amount"
- Result Attribute: "Closing Balance"
- Keep Records: Same
- Tolerance Threshold: 0.0
Result: The filter returns only cases where the calculation exactly matches (Opening Balance + Transaction Amount = Closing Balance).
Insights: This helps verify accounting accuracy and can be used to confirm that all transactions are properly recorded with correct balance updates.
Example 6: Finding Consistent Unit Price Calculations
Scenario: Identify cases where the unit price calculation is correct (Total Amount / Quantity = Unit Price), which can be used to validate pricing consistency across orders.
Settings:
- First Operand: "Total Amount"
- Operation Type: Divide
- Second Operand: "Quantity"
- Result Attribute: "Unit Price"
- Keep Records: Same
- Tolerance Threshold: 0.01
Result: The filter returns cases where the calculated unit price matches the stored unit price within the tolerance threshold.
Insights: This helps identify properly calculated orders that can serve as benchmarks, while excluding these from analysis allows you to focus on problematic cases.
Output
The filter returns a new dataset containing only the cases that meet the specified comparison criteria. For case-level filtering (when using case attributes), entire cases are kept or removed based on whether they meet the condition. For event-level filtering (when using event attributes), cases are kept if they contain at least one event meeting the specified condition.
All three attributes (First Operand, Second Operand, and Result Attribute) must be from the same source - either all case attributes or all event attributes. If attributes are from different sources, the filter returns the original dataset unchanged.
The filter preserves all original events and attributes in the returned cases.
Technical Notes
- Filter Type: Case-level filter (removes entire cases based on attribute comparisons)
- Data Source Flexibility: Supports both case attributes and event attributes, but all three must be from the same source
- Numeric Types Supported: Double, Single, Int32 (integer), Int64 (long integer)
- Division by Zero Handling: Division operations only proceed if the second operand is greater than zero; otherwise, the result is null
- Null Value Handling: If any of the three required values are null, the calculation result is considered null
- Threshold Processing: After calculating the difference, the tolerance threshold is applied to handle floating-point precision issues
- Performance: Efficiently validates calculations across large datasets with optimized numeric comparisons
This documentation is part of the mindzieStudio process mining platform.