How to Check Carbohydrate Values Imported Between Apps

You import a food diary from one nutrition app into another. Calories look similar, protein and fat match, but the carbohydrate number has changed.

This does not necessarily mean either app has made a calculation error.

Nutrition databases, regional labeling rules and import formats can define or handle carbohydrates differently. A correct-looking number may also be attached to the wrong serving size or food preparation state.

The safest approach is to identify what the original carbohydrate value represents before changing it.

Start with the two main carbohydrate conventions

One of the most important differences involves dietary fiber.

In many US food databases, total carbohydrate includes dietary fiber.

On EU nutrition labels, the declared value for carbohydrate generally excludes fiber, which may be listed separately.

For example, consider a hypothetical food containing:

The difference is not necessarily lost carbohydrate.

It may simply reflect two different reporting conventions.

However, this subtraction is only valid when the figures refer to the same food, same weight basis and compatible analytical definitions.

Do not apply it automatically to every imported record.

Total carbohydrate, available carbohydrate and net carbs

These terms are related but not always interchangeable.

Total carbohydrate: A reporting category commonly used in US nutrition data that generally includes fiber.

Available carbohydrate: Carbohydrate intended to represent digestible carbohydrate, with the exact analytical or calculation method depending on the data source.

Net carbs: A term often used in diet and tracking apps. Its calculation can vary, especially when sugar alcohols or other ingredients are involved.

A simple net-carb calculation sometimes used in consumer apps is total carbohydrate minus fiber.

But that does not establish that every app uses the same formula.

If the food contains polyols, resistant starch or other specialized ingredients, the difference can be more complicated.

When importing data, preserve the source definition rather than guessing from the field name.

A practical import-checking example

Imagine an app exports this record:

A receiving app might expect carbohydrates excluding fiber.

If it imports 33 g directly into that field, the result can appear higher than expected.

Under the simplified assumption that the values are compatible, carbohydrates excluding fiber would be approximately:

33 g − 11 g = 22 g.

The original 33 g is not automatically wrong.

The problem may be that it has been assigned to a field with a different meaning.

This example is illustrative and is not a verified nutritional profile for a particular bean product.

Check the serving size before changing macros

A mismatch can come from weight rather than carbohydrate definitions.

For example:

• Source app: 30 g dry oats.
• Destination app: 100 g dry oats.
• Imported carbohydrate value: still based on 30 g.

The receiving app may show an unexpected value because the serving basis was not transferred correctly.

Check:

1. Serving quantity.
2. Serving unit.
3. Grams per serving.
4. Number of servings.
5. Whether values are per 100 g or per portion.

If 60 g of a product contains 36 g carbohydrates, then 100 g contains 60 g, assuming the same product and composition.

The correct conversion is proportional:

Carbohydrates per 100 g = carbohydrates in portion ÷ portion weight × 100.

Always verify the weight basis before comparing database entries.

Raw and cooked foods create another mismatch

Cooking changes the water content and therefore the nutrient concentration per 100 g.

Dry rice and cooked rice are not interchangeable entries.

Neither are dry lentils and boiled lentils.

An imported food record may preserve the original grams but accidentally map to a different preparation state.

For example, 100 g dry rice and 100 g cooked rice contain very different amounts of carbohydrate.

This is largely because cooked rice contains substantially more water.

When investigating a discrepancy, confirm whether both apps refer to the same food state.

Sugar alcohols and specialty foods

Protein bars, sugar-free sweets and some low-carbohydrate products require additional attention.

Depending on the label and jurisdiction, polyols may be reported separately or handled differently in carbohydrate calculations.

Some apps deduct all polyols when displaying net carbs.

Others use different rules or retain the declared carbohydrate value.

Do not assume that a product's net-carb marketing claim equals the carbohydrate value required by another database.

For packaged foods, compare the original manufacturer's label with the app's fields.

If a specific polyol calculation is relevant to a medical dietary plan, use professional guidance rather than an unverified app formula.

Check the import mapping field by field

A structured audit is more reliable than adjusting numbers by eye.

If the export file uses ambiguous field names such as carbs, carbohydrate or carbs_total, inspect the documentation for the exporting service.

A field name alone is not sufficient proof of its definition.

Do not use calories to reverse-engineer carbs blindly

A common troubleshooting approach is to subtract protein and fat energy from total calories, then assign the remainder to carbohydrates.

This can produce misleading results.

Energy values may include contributions from fiber, polyols, alcohol or organic acids under different calculation systems.

Labels also use permitted rounding.

For example, EU energy calculations generally use different energy factors for available carbohydrates and fiber.

As a result, carbohydrate grams cannot always be reconstructed exactly from calories, protein and fat.

Use the declared nutrient fields and their definitions first.

Treat calorie arithmetic as a rough consistency check, not a definitive correction method.

A seven-step verification workflow

1. Preserve the original import

Keep the source record or export file unchanged.

Do not overwrite the original values before identifying the issue.

2. Identify the source database

Determine whether the values come from a manufacturer label, a national food database, a user-created entry or another app.

Different sources have different reliability levels.

3. Check the carbohydrate definition

Find out whether the field includes fiber.

Also check whether net carbs or available carbohydrate is being used.

4. Match the serving basis

Confirm that both apps use the same weight and unit.

Pay attention to dry versus cooked weights.

5. Compare the original label

For packaged foods, use the current manufacturer label for the exact product and market.

Do not substitute a similar product merely because its name matches.

6. Correct the field mapping

If the apps use different carbohydrate definitions, map the fields appropriately.

Do not silently alter the source record.

7. Flag unresolved discrepancies

If definitions remain unclear, mark the record for review instead of presenting a guessed number as exact.

Example: comparing a US database with an EU label

Suppose a food database reports:

• Total carbohydrate: 28 g.
• Fiber: 6 g.

An EU label for a comparable food reports carbohydrate around 22 g and fiber separately.

The figures may be consistent after accounting for the reporting convention.

But they are not automatically identical.

Differences may also arise from:

• Different products or recipes.
• Laboratory methods.
• Ingredient variations.
• Rounding.
• Moisture content.
• Product reformulation.

Do not force two independent records to match simply because their food names are similar.

What if calories match but carbs do not?

Matching calories does not prove that carbohydrate fields are equivalent.

The calorie value may have been imported independently from the macro values.

Different energy calculation conventions and rounding can also contribute.

Check the source fields individually.

If protein and fat match, but carbohydrates differ by approximately the reported fiber amount, that is a useful clue.

It is not proof until the definitions and serving basis have been verified.

What if the imported value is zero?

Zero can mean several different things:

• The product genuinely has very little carbohydrate.
• The source reports a rounded zero.
• The field was missing and the importer replaced it with zero.
• The importer failed to recognize the source field.
• A database record is incomplete.

A missing value should not automatically be treated as a measured zero.

For nutrition tracking, distinguishing unknown from zero prevents misleading totals.

When the discrepancy matters most

A small difference may have limited practical impact for casual food tracking.

More careful verification is warranted when:

• Someone follows a medically prescribed carbohydrate plan.
• Carbohydrate counting is used for diabetes management.
• Imported values are used to make clinical decisions.
• A food is consumed frequently.
• A large number of records share the same mapping error.
• The app automatically generates meal plans from imported macro data.

For medical carbohydrate counting, follow the instructions of the treating healthcare professional.

Do not rely on an unverified conversion rule for medication-related decisions.

A useful rule for app developers

Store both the value and its meaning whenever possible.

For example, a structured record can preserve:

• Carbohydrate value.
• Carbohydrate definition.
• Fiber value.
• Original source.
• Serving weight.
• Food preparation state.
• Import timestamp.
• Conversion method, if any.

This is more robust than storing a single field named carbs without metadata.

When a conversion is necessary, retain the original value so it can be audited later.

Sources

• USDA FoodData Central — US food composition data and nutrient definitions.
• EU Regulation No 1169/2011 — European nutrition labeling and energy conversion rules.
• European Commission: Food Information to Consumers — EU labeling framework.
• FDA: Nutrition Facts Label — US nutrition labeling information.

The key takeaway

When carbohydrate values change during an app import, check definitions before correcting numbers.

The difference may come from fiber treatment, serving size, cooking state, product variation or import mapping.

Preserve the source data, verify the food and portion, and only convert values when the underlying definitions support the calculation.