Skip to main content

"Expected to have a hard decimal place" Error — How to Fix Decimal Formatting Issues

Why is my CTP08 field missing decimal places?

Mike Mason avatar
Written by Mike Mason
Updated today

Audience: EDI developers, B2B integration teams, accounting teams processing invoices

When to use this article: Use this when a transaction is rejected due to decimal formatting issues in amount fields — either caught by Orderful validation (transaction status: Invalid) or rejected by your trading partner (acknowledgment status: Rejected, or a partner-reported error via email, 824, or 864).

What This Error Means

The X12 specification allows trading partners to choose how numeric fields are read by assigning a data type to each field. That type is defined in the partner's EDI guidelines and tells you and your system how to interpret a number: whether it includes an explicit decimal point, or whether the decimal position is implied.

When you open your trading partner's guidelines in Orderful, each amount field will show a type such as R, N2, or N4. That type is the contract for how the value should be formatted. If the value you send doesn't match the type the partner has defined, their system will misread the amount and reject the transaction.

For example, a field representing a dollar amount typed as N2 has 2 implied decimal places. The value 350820 doesn't mean a total amount of $350,820 — it means $3,508.20, because the last 2 digits are always treated as the decimal portion. A partner expecting R type (explicit decimal) receiving 350820 has no way to know a decimal was intended — they read it as $350,820.00.

The reverse is also possible, If your system sends 3508.20 but the partner's guideline defines the field as N2, causing their system to misparse the decimal point as an invalid character.

EDI Numeric Field Types

EDI uses specific data types to define how numbers are formatted. Understanding these is key to diagnosing decimal mismatches:

Type

Name

Description

Example: $345.46

R

Decimal number

Explicit decimal point included

345.46

N0

Integer

No decimal places implied

345 (whole number only)

N1

Numeric, 1 implied decimal

Last 1 digit is the decimal

3455

N2

Numeric, 2 implied decimals

Last 2 digits are the decimal

34546

N4

Numeric, 4 implied decimals

Last 4 digits are the decimal

3454600

D

Decimal with explicit point

Same as R, used in specific segments

345.46

The mismatch happens when your system sends a value in one format (e.g., N2 implied decimals: 350820) but the trading partner expects explicit decimal notation (e.g., R type: 3508.20). Their system reads 350820 as $350,820.00 instead of $3,508.20.

Commonly Affected Amount Fields

The following are the most frequently reported fields, though any numeric amount field can be affected depending on your trading partner's guidelines.

X12 Element

Segment

Description

Common Requirement

CTP08

CTP

Contract price

N2 or R, 2 decimal places

IT104

IT1

Invoice unit price

N2 or R, 2 decimal places

TDS01

TDS

Total invoice amount

N2 or R, 2 decimal places

SAC05

SAC

Service/allowance/charge amount

N2 or R, 2 decimal places

N905

N9

Reference amount

Varies by partner

CTP05

CTP

Quantity

N2 or R, varies

How to Diagnose the Specific Issue

Step 1 — Determine where the error is coming from

  • The partner communicated the error externally (email, 824, or 864)

    • Transaction validation status: Valid

    • Transaction acknowledgment status of Accepted.

    • Error: Email, 824, or 864
      ​
      The transaction will show Valid and Accepted because Orderful has no way to know the partner rejected it separately.
      The partner may describe the error in different ways — "out of balance," "amount mismatch," "decimal error," "invoice total doesn't match", "amount formatting invalid", ...
      ​
      Your goal is to map their description back to a specific X12 element or JSON path. Use the table above to match their description to a field.
      ​

  • The partner rejected the transaction via 997

    • Transaction validation status: Valid

    • Transaction acknowledgment status of Rejected.
      ​
      1. Open the 997 acknowledgment in Orderful
      2. Look for the AK3/AK4 segments — Your partner may reference the segment ID and element position of the rejected field.
      ​
      ​Example: 997 reporting a error on the segment CTP, element position 8 (CTP08), received value 350820, error code 6 (invalid value).

      AK3*CTP*12**8~ AK4*8**6*350820~

  • Orderful is enforcing semantic validation (transaction status: Invalid)

    • Transaction validation status: Invalid
      ​
      Orderful may validate calculated amount fields for some partners.
      If this is the case, the transaction will have a validation status of Invalid and the error will appear in the Rules Editor tab, pinpointing the exact JSON path and the expected value. For example:

      'monetaryAmount' must equal sum of quantity times unit price across all items with 2 implied decimal. Expected 350800, got 3508.

Step 2 — Check how you're sending the amount

  1. In Orderful, open the transaction

  2. Use the earch bar to find the impacted field

  3. Note exactly how the amount appears (e.g., 350820 vs 3508.20 vs 3508200)

Step 3 — Confirm partner requirements

  1. In Orderful, open the impacted transaction

  2. Go to Rules Editor

  3. Click on View Leader Guideline.

  4. In the guideline, look for decimal place requirements on the specific amount field.

Alternatively, you can also:

  1. Go to Relationships

  2. Find your impacted relationship (you can use the filters)

  3. Click Guidelines

  4. In the guideline, look for decimal place requirements on the specific amount field.

If the guidelines type matches what you're sending, contact your trading partner directly to confirm their expected format.

Fix 1: Add or Correct Explicit Decimal Places

When this applies: Your system sends amounts as integers or N2 implied decimals (e.g., 350820) but the partner requires explicit decimal notation (e.g., 3508.20).

  1. Open the transaction

  2. Go to Rules Editor

  3. Click on the impacted element

  4. Write a rule. Use a DIVIDE and ROUND functions to insert the decimal point at the correct position.

    Example — Convert N2 implied decimals to explicit 2-decimal format:

    ROUND(DIVIDE($transactionSets.*.IT1_loop.*.baselineItemDataInvoice.*.unitPrice, 100), 2)

  5. Save the rule.

    • If the error was caught by Orderful validation (status: Invalid): Orderful will apply it to the existing transaction automatically. No resend needed.

    • If the error came from your trading partner: Save the rule, then resend the transaction. Ask your trading partner to confirm receipt and that the new format resolves the rejection.

Fix 2: Remove Explicit Decimal to Match Implied Decimal Format

When this applies: Your system sends amounts with an explicit decimal point (e.g., 3508.20) but the partner's guideline defines the field as N2 (implied decimals), expecting 350820.

  1. Open the transaction

  2. Go to Rules Editor

  3. Click on the impacted element

  4. Write a rule. Use a MULTIPLY and ROUND functions to add implied decimals

    Example — Convert regular decimals to implicit 2-decimal format:

    ROUND(MULTIPLY($transactionSets.*.totalMonetaryValueSummary.*.amount, 100), 0)

  5. Save the rule.

    • If the error was caught by Orderful validation (status: Invalid): Orderful will apply it to the existing transaction automatically. No resend needed.

    • If the error came from your trading partner: Save the rule, then resend the transaction. Ask your trading partner to confirm receipt and that the new format resolves the rejection.

Fix 3: Remove Decimal Places to Match Integer Format

When this applies: Your system sends amounts with decimal places (e.g., 1098.00) but the partner's guideline defines the field as N0 (integer, no decimals), expecting 1098.

  1. Open the transaction

  2. Go to Rules Editor

  3. Click on the impacted element

  4. Write a rule. Use a ROUND functions to add implied decimals

    Example — Convert regular decimals to integer format:

    ROUND($transactionSets.*.totalMonetaryValueSummary.*.amount, 0)

  5. Save the rule.

    • If the error was caught by Orderful validation (status: Invalid): Orderful will apply it to the existing transaction automatically. No resend needed.

    • If the error came from your trading partner: Save the rule, then resend the transaction. Ask your trading partner to confirm receipt and that the new format resolves the rejection.

What to Send Orderful Support

If you still have trouble to resolve your issues, contact [email protected] and include:

  • Transaction ID from the failed transaction in Orderful

  • Trading partner name and relationship details

  • Exact error message from the trading partner (copy/paste the full text)

  • Field name being rejected (e.g., CTP08, IT104)

  • Amount you intended to send (e.g., "should be $3,508.20")

  • How the amount appears in the raw EDI (e.g., "showing as 350820")

  • Partner's decimal requirements if known (e.g., "requires 2 decimal places")

This information allows our team to create the correct transformation rules immediately.

Frequently Asked Questions

Frequently Asked Questions

Do I need to resend transactions after creating a formatting rule?
It depends on where the error was caught. If Orderful caught the error (transaction status: Invalid), saving the rule fixes the existing transaction — no resend needed. If your trading partner caught the error and rejected it, you need to resend the transaction after saving the rule, and ask them to confirm it's resolved.

My trading partner accepts the same transactions from other vendors. Why are mine being rejected?
Different EDI systems format amounts differently. Your other vendors may already be sending explicit decimal notation, while your system uses implied decimals. This is a common difference between platforms and is fixed with a formatting rule in Orderful.
​

Can I fix this by changing how my system generates the EDI file?
Yes — if you have control over your EDI generation, updating your system to send the correct decimal format is a valid fix. However, a formatting rule in Orderful is often faster and doesn't require changes to your source system.
​

Will formatting rules affect other trading partners?
No. Rules are relationship-specific and only apply to transactions for the partner they're configured for.
​

How do I confirm the rule is working?
After saving the rule, check the JSON payload in the Rules Editor on a new or re-evaluated transaction. The amount field should now show the correct format (e.g., 3508.20 instead of 350820).


​The partner says the invoice is "out of balance" — is this the same issue?
Often yes. "Out of balance" usually means the line item amounts don't sum to the transaction total, which can happen when one field is formatted differently from the others. Check all amount fields — TDS01, IT104, and SAC05 — to make sure they're all using the same decimal format.

Did this answer your question?