2 Way Match

Overview

The 2 Way Match enrichment compares numerical values from two sets of activities within a case to determine if they match, creating a powerful validation mechanism for document reconciliation and process compliance analysis. This enrichment calculates aggregate values (such as sum, average, first, or last occurrence) from specified activities and their associated numeric attributes, then compares these values to identify matches or discrepancies. The enrichment creates both a boolean attribute indicating whether the values match and an optional difference attribute showing the variance between the two values.

This enrichment is essential in procurement, financial, and logistics processes where multiple documents or activities need to be reconciled against each other. For instance, in a procure-to-pay process, you can verify that purchase order quantities match goods receipt quantities, or that invoice amounts align with purchase order values. The enrichment operates at the case level, making it ideal for validating multi-step processes where different activities record related information that should be consistent. By supporting multiple aggregation methods (sum, average, min, max, first, last), the enrichment adapts to various business scenarios, from simple last-value comparisons to complex summations across multiple line items.

The 2 Way Match enrichment provides the foundation for three-way and four-way matching scenarios by establishing the basic comparison logic. Once you've identified mismatches, you can use filtering and analytics to understand patterns in discrepancies, measure process compliance rates, and route cases with mismatches for manual review or approval.

Common Uses

  • Validate purchase order quantities against goods receipt quantities in procurement processes
  • Compare invoice amounts to purchase order values for financial compliance and payment approval
  • Reconcile sales order quantities with shipment quantities in order fulfillment
  • Verify that planned production quantities match actual production output in manufacturing
  • Compare requisition amounts to approved budget allocations in spend management
  • Validate service delivery hours against contracted hours in professional services
  • Reconcile inventory counts between physical counts and system records
  • Verify that customer order quantities match picking and packing quantities in warehouse operations

Settings

Activity Names 1: Specify one or more activities that represent the first document or transaction type in your comparison. For example, in a procurement process, this might be "CreatePurchaseOrderLine" or "UpdatePurchaseOrderLine" to capture the ordered quantities. You can select multiple activities if the same type of information appears in different activity names. The enrichment will retrieve the numeric value from these activities based on the Event Selection 1 method you choose.

Event Selection 1: Choose how to aggregate values when multiple instances of Activity Names 1 exist in a case. Options include:

  • First: Uses the value from the first occurrence of the activity in the case
  • Last: Uses the value from the last occurrence (default - most common for document updates)
  • Sum: Adds together all values from all occurrences (ideal for line-item totals)
  • Average: Calculates the mean of all values
  • Min: Uses the smallest value found
  • Max: Uses the largest value found

Activity Names 2: Specify one or more activities that represent the second document or transaction type to compare against the first. For example, in procurement, this might be "ProductReceipt" or "GoodsReceipt" to capture the received quantities. The enrichment will compare the aggregated value from these activities against the value from Activity Names 1.

Event Selection 2: Choose how to aggregate values when multiple instances of Activity Names 2 exist in a case. This uses the same options as Event Selection 1. The default is "Sum" which is commonly used for receipts that may occur in multiple shipments. For example, if a purchase order for 100 units is fulfilled through three shipments (40, 35, and 25 units), selecting "Sum" will correctly total 100 units for comparison.

Column Name: Select the numeric event attribute that contains the values to compare. This must be a numeric field (integer, decimal, or float) that exists on the events for both activity sets. Common examples include "Quantity," "Amount," "Value," "Hours," or "Weight." The enrichment will extract this attribute's value from the specified activities and perform the comparison.

New Attribute Name: Specify the name for the boolean case attribute that will store the match result. Choose a descriptive name that clearly indicates what is being compared, such as "PO_Matches_GR_Quantity" or "Invoice_Amount_Matches_PO." This attribute will contain True when the values match exactly and False when they differ. Default example: "Quantity for CreatePurchaseOrderLine = ProductReceipt"

New Attribute Difference Name: Optionally specify the name for a numeric case attribute that will store the difference between the two values. This attribute calculates Value1 minus Value2, allowing you to analyze the magnitude and direction of discrepancies. For example, a positive difference indicates the first value exceeds the second (e.g., ordered more than received), while a negative difference indicates the opposite. Leave this blank if you only need the boolean match indicator. Default example: "Quantity difference CreatePurchaseOrderLine - ProductReceipt"

Filter Cases (Advanced): Optionally apply filters to limit which cases are evaluated by this enrichment. This advanced setting allows you to perform the 2-way match only on cases meeting specific criteria, such as cases with certain statuses, date ranges, or attribute values. Cases not matching the filter will not have the new attributes calculated.

Examples

Example 1: Purchase Order to Goods Receipt Quantity Matching

Scenario: In a procure-to-pay process, you need to validate that the total quantity received matches the quantity ordered. Purchase orders may be updated multiple times before final approval, and goods may be received in multiple shipments. You want to identify cases where received quantities don't match the final ordered quantity.

Settings:

  • Activity Names 1: CreatePurchaseOrderLine, UpdatePurchaseOrderLine
  • Event Selection 1: Last
  • Activity Names 2: GoodsReceipt, ProductReceipt
  • Event Selection 2: Sum
  • Column Name: Quantity
  • New Attribute Name: PO_Quantity_Matches_GR
  • New Attribute Difference Name: PO_GR_Quantity_Variance

Output: Creates two new case attributes:

  1. PO_Quantity_Matches_GR (Boolean):

    • True: Cases where final ordered quantity equals total received quantity (e.g., ordered 100, received 100)
    • False: Cases with discrepancies (e.g., ordered 100, received 95 or 105)
  2. PO_GR_Quantity_Variance (Numeric):

    • 0: Perfect match
    • +5: Ordered 5 units more than received (short shipment)
    • -5: Received 5 units more than ordered (over shipment)

Sample data:

  • Case 12345: Ordered 100 units (last PO update), received in 3 shipments (40, 35, 25 = 100 total) → PO_Quantity_Matches_GR = True, Variance = 0
  • Case 12346: Ordered 50 units, received 48 units → PO_Quantity_Matches_GR = False, Variance = +2
  • Case 12347: Ordered 75 units, received 80 units → PO_Quantity_Matches_GR = False, Variance = -5

Insights: This enrichment enables you to filter for cases with quantity discrepancies, analyze the frequency and magnitude of over/under shipments, identify suppliers with consistent quantity issues, and route mismatched cases for approval or investigation. You can calculate metrics like "98% of orders have exact quantity matches" or "average quantity variance is +2.3 units, indicating slight under-delivery trend."

Example 2: Invoice to Purchase Order Amount Validation

Scenario: In accounts payable, you need to verify that invoice amounts match the original purchase order values before processing payment. This two-way match ensures that you're only paying for what was actually ordered and helps catch pricing discrepancies or invoice errors.

Settings:

  • Activity Names 1: CreatePurchaseOrder, ApprovePurchaseOrder
  • Event Selection 1: Last
  • Activity Names 2: ReceiveInvoice
  • Event Selection 2: Sum
  • Column Name: TotalAmount
  • New Attribute Name: Invoice_Matches_PO_Amount
  • New Attribute Difference Name: Invoice_PO_Amount_Difference

Output: Creates two new case attributes showing invoice-to-PO matching:

  1. Invoice_Matches_PO_Amount (Boolean):

    • True: Invoice amount exactly matches PO amount (e.g., both $5,000.00)
    • False: Amounts differ (e.g., PO for $5,000.00, invoice for $5,250.00)
  2. Invoice_PO_Amount_Difference (Numeric):

    • 0.00: Exact match
    • +500.00: PO amount exceeds invoice by $500 (undercharged)
    • -250.00: Invoice exceeds PO by $250 (overcharged, requires approval)

Sample data:

  • Case INV-001: PO Amount $10,000, Invoice Amount $10,000 → Match = True, Difference = $0
  • Case INV-002: PO Amount $7,500, Invoice Amount $7,750 → Match = False, Difference = -$250
  • Case INV-003: PO Amount $3,200, Invoice Amount $3,200 → Match = True, Difference = $0

Insights: This enables automatic approval routing for matching invoices, flags invoices exceeding PO amounts for manual review, identifies systematic pricing issues with specific vendors, and measures straight-through processing rates. You can create business rules like "auto-approve if Invoice_Matches_PO_Amount is True" or "require manager approval if Invoice_PO_Amount_Difference exceeds $500."

Example 3: Sales Order to Shipment Quantity Reconciliation

Scenario: In an order fulfillment process, you need to ensure that the quantity shipped matches what the customer ordered. Orders may be modified before fulfillment, and shipments may occur in multiple packages. This validation helps identify short shipments and ensures customer satisfaction.

Settings:

  • Activity Names 1: CreateSalesOrder, ModifySalesOrder
  • Event Selection 1: Last
  • Activity Names 2: ShipProduct, ConfirmShipment
  • Event Selection 2: Sum
  • Column Name: OrderedQuantity
  • New Attribute Name: Order_Shipment_Quantity_Match
  • New Attribute Difference Name: Unshipped_Quantity

Output: Creates attributes tracking order fulfillment accuracy:

  1. Order_Shipment_Quantity_Match (Boolean):

    • True: Complete fulfillment (ordered 50, shipped 50)
    • False: Partial or over fulfillment (ordered 50, shipped 48 or 52)
  2. Unshipped_Quantity (Numeric):

    • 0: Fully shipped
    • +2: 2 units short (backorder situation)
    • -2: 2 units over-shipped (potential inventory issue)

Sample data:

  • Order SO-5001: Ordered 200 units, shipped in 4 batches (75, 50, 50, 25 = 200) → Match = True, Unshipped = 0
  • Order SO-5002: Ordered 150 units, shipped 145 units → Match = False, Unshipped = +5
  • Order SO-5003: Ordered 100 units, shipped 100 units → Match = True, Unshipped = 0

Insights: This enrichment helps measure order fulfillment accuracy rates, identify products frequently experiencing short shipments, calculate backorder quantities and trends, and trigger customer service notifications for incomplete shipments. You can create KPIs like "95% complete fill rate" or "average unfulfilled quantity: 2.3 units per incomplete order."

Example 4: Manufacturing Production Plan to Actual Output

Scenario: In a manufacturing process, you need to compare planned production quantities against actual output to measure production efficiency and identify capacity or quality issues. Production plans may be updated, and output is recorded as batches are completed.

Settings:

  • Activity Names 1: CreateProductionOrder, UpdateProductionPlan
  • Event Selection 1: Last
  • Activity Names 2: RecordProduction, CompleteProductionBatch
  • Event Selection 2: Sum
  • Column Name: Quantity
  • New Attribute Name: Production_Met_Plan
  • New Attribute Difference Name: Production_Variance

Output: Creates attributes measuring production performance:

  1. Production_Met_Plan (Boolean):

    • True: Actual production equals plan (planned 1000, produced 1000)
    • False: Over or under production (planned 1000, produced 950 or 1050)
  2. Production_Variance (Numeric):

    • 0: Met plan exactly
    • +50: Under-produced by 50 units (capacity or quality issue)
    • -50: Over-produced by 50 units (efficiency gain or forecasting issue)

Sample data:

  • Production Order PR-8001: Planned 5000 units, produced 5000 → Met_Plan = True, Variance = 0
  • Production Order PR-8002: Planned 3000 units, produced 2850 → Met_Plan = False, Variance = +150
  • Production Order PR-8003: Planned 1500 units, produced 1520 → Met_Plan = False, Variance = -20

Insights: This enables calculation of production efficiency rates, identification of production lines with consistent under-performance, analysis of variance patterns by product type or shift, and early warning for capacity constraints. You can measure "85% of production orders meet plan exactly" or "average production variance: -2.5% (slight over-production)."

Example 5: Service Hours - Contracted vs. Delivered

Scenario: In a professional services organization, you need to verify that the hours delivered to clients match the contracted hours in the service agreement. Service contracts may be amended, and hours are logged across multiple service delivery activities.

Settings:

  • Activity Names 1: CreateServiceContract, AmendServiceContract
  • Event Selection 1: Last
  • Activity Names 2: LogServiceHours, SubmitTimesheet
  • Event Selection 2: Sum
  • Column Name: Hours
  • New Attribute Name: Hours_Match_Contract
  • New Attribute Difference Name: Hours_Variance

Output: Creates attributes for service delivery validation:

  1. Hours_Match_Contract (Boolean):

    • True: Delivered hours equal contracted hours (contracted 80, delivered 80)
    • False: Over or under delivery (contracted 80, delivered 75 or 85)
  2. Hours_Variance (Numeric):

    • 0: Exact match
    • +5: Under-delivered by 5 hours (potential client dissatisfaction)
    • -10: Over-delivered by 10 hours (revenue leakage if not billable)

Sample data:

  • Project SVC-2001: Contracted 160 hours, delivered 160 hours → Match = True, Variance = 0
  • Project SVC-2002: Contracted 120 hours, delivered 115 hours → Match = False, Variance = +5
  • Project SVC-2003: Contracted 200 hours, delivered 215 hours → Match = False, Variance = -15

Insights: This enrichment enables measurement of service delivery accuracy, identification of projects with scope creep (over-delivery), detection of under-delivery requiring corrective action, and analysis of billing accuracy. You can track "92% of projects deliver contracted hours" or "average over-delivery: 3.2 hours per project."

Output

The 2 Way Match enrichment creates one or two new case attributes depending on your configuration:

Match Indicator Attribute (Always Created): A boolean attribute with the name specified in "New Attribute Name" that contains:

  • True: When the aggregated value from Activity Names 1 equals the aggregated value from Activity Names 2
  • False: When the values differ by any amount
  • No value (null): When either or both activity sets don't exist in the case, or when the specified column doesn't contain values for the activities

Difference Attribute (Optional): If you specify a "New Attribute Difference Name," the enrichment creates a numeric attribute containing the difference calculated as Value1 minus Value2:

  • Positive values: Indicate the first value exceeds the second (e.g., ordered more than received)
  • Negative values: Indicate the second value exceeds the first (e.g., received more than ordered)
  • Zero: Indicates an exact match
  • No value (null): When the comparison cannot be performed due to missing activities or values

Both attributes are created as derived case attributes and integrate seamlessly with other mindzieStudio features:

Filtering: Create filters to show only cases with mismatches (Match = False), cases with significant variances (Difference > threshold), or cases with specific variance patterns (Difference > 0 for short shipments).

Conformance Analysis: Calculate match rates and variance statistics across your entire dataset or specific segments. For example, measure "98% of purchase orders have matching receipts" or "average quantity variance: 2.3 units."

Process Visualization: Split process flows based on match results to visualize different paths for matched versus mismatched cases, helping identify where mismatches are introduced or resolved.

Calculators: Use the boolean match attribute in logical expressions to create complex validation rules, such as combining two-way match results with other compliance checks.

Dashboards and KPIs: Create metrics showing match rates over time, variance distributions, and compliance trends. Build charts showing variance patterns by supplier, product category, or time period.

Automation and Routing: Use match results to drive process automation, such as auto-approving cases where the match is True and routing cases with False to manual review queues.

The enrichment performs comparisons only on cases where both activity sets exist and contain numeric values in the specified column. Cases where activities or values are missing will have null values for the output attributes, allowing you to identify incomplete cases separately from mismatched cases.

See Also

  • Compare Case Attributes - For comparing two case-level attributes directly without aggregating from activities
  • Compare Event Attributes for Two Activities - For comparing event attributes from two specific activities without aggregation
  • Attribute Changes Between Two Activities - For detecting changes in attribute values between two activities
  • Subtract - For calculating differences between case attributes created by other enrichments
  • Filter Process Log - For filtering cases based on match results and variances
  • Divide - For calculating ratio-based comparisons between matched values

This documentation is part of the mindzie Studio process mining platform.

An error has occurred. This application may no longer respond until reloaded. Reload ??