With over 20 years of experience, we transform your digital presence. We specialize in website and E-Shop development, SEO and Digital Marketing, ERP software and smart automation that take your business to the next level.
Address:
154 Egnatia Street, Thessaloniki 546 36
Phone:
+30 231 231 4095
E-mail:
hello@twodots.gr
How signed and unsigned numbers affect e-shops, APIs, ERP, payments and databases without hidden errors.
DesignNews« article on unsigned and signed binary numbers explains a seemingly »low-level” concept in electronics and computing: how a computer interprets sequences of 0 and 1 as numbers, sometimes only positive and sometimes positive and negative. For an e-shop owner, this may sound far removed from sales, conversion rate, or inventory. In practice, however, Binary Numbers are behind every product price, every available inventory, every order ID, every refund, every API integration with an e-commerce ERP, and every report that passes from the database to the dashboard.
The crucial point is that the same pattern of bits can mean different numbers, depending on whether the system treats them as unsigned binary numbers or as signed binary numbers. An 8-bit field, for example, can express values from 0 to 255 as unsigned, while as signed with two's complement it expresses values from -128 to 127. The difference is not academic. If an inventory, customer ID, or discount amount is passed from one system to another with the wrong data types, you may see a negative quantity, an incorrect charge, a failed payment systems reconciliation, or an unexplained bug at checkout.
As shown in the graph below, choosing signed or unsigned drastically changes the maximum positive value that can be stored in the same number of bits. The data is derived from the standard calculation formulas: unsigned maximum 2^n – 1 and signed two's complement maximum 2^(n-1) – 1.
Source: DesignNews and typical binary representation types 2^n – 1 and 2^(n-1) – 1
A modern online store is not just a showcase of products. It is a system that connects e-commerce platforms, databases, ERP, courier APIs, banks, payment providers, marketing automation, analytics tools and billing systems. Each connection transfers numerical data. Inventory management sends available quantities. ERP updates prices, VAT and discounts. Payment gateway returns transaction amounts, fees, refunds and authorization codes. Database stores IDs, timestamps and counters. All of this, at a technical level, results in a binary system.
The problem occurs when two systems disagree on how to interpret it. If an API sends an unsigned value and the receiving system interprets it as signed, then large positive numbers can appear as negative. If a field has a smaller bit depth than the business reality requires, an integer overflow occurs. If a developer assumes that inventory will never exceed 32,767 units and uses signed 16-bit logic, a successful sale, marketplace sync, or mass product import can reveal the error in the most expensive way.
For an e-commerce owner, the practical lesson isn't to write low-level code yourself. It's to know what questions to ask developers, agencies, and SaaS vendors. How are database integers defined? Are there limits on product IDs or order IDs? Are amounts stored in cents as integers or in decimal fields? Do refunds allow negative values or are they recorded as separate positive transactions? Computer arithmetic affects the reliability of the commerce system more than it appears on the admin panel screen.
In unsigned binary numbers, all bits are used to express the size of a non-negative number. This is ideal when the value cannot logically fall below zero: product number, visit count, stock quantity, customer ID, order ID, or coupon usage counter. With n bits, the range is from 0 to 2^n – 1. Thus, a 16-bit unsigned field goes up to 65,535, while a 32-bit unsigned goes up to 4,294,967,295.
In signed binary numbers, part of the representation is used to represent negative values. The most common model in modern processors is two's complement, where the most significant bit functions practically as the sign bit and the range for n bits is from -2^(n-1) to 2^(n-1)-1. For an 8-bit signed value, this means -128 to 127. For a 16-bit signed value, -32,768 to 32,767. The value of two's complement is that it allows efficient addition and subtraction in hardware, without separate logic for negative numbers.
On the business side, signed values are essential where there is real meaning to a negative number: accounting transactions, credit balances, inventory differences, inventory corrections, refunds, manual adjustments, and profit/loss reports. Conversely, unsigned fields are useful when negative values don’t make sense and we want a larger positive range with the same number of bits. Choosing the wrong one isn’t just a technical flaw; it can impact reporting, team confidence, and the customer experience.
DesignNews refers to the historical and technical distinction between ways of representing signed numbers. In sign-magnitude, one bit indicates the sign and the rest the magnitude. It is easy to understand, but it creates two forms for zero, positive and negative, which complicates arithmetic. In one's complement, a negative number is obtained by reversing all the bits of the corresponding positive number, but here too there is the issue of double zero. Two's complement solves this problem and has therefore prevailed in modern computer arithmetic.
For e-shops, this detail becomes important when data travels between older systems, custom ERP, embedded devices, barcode scanners, POS or middleware that uses different conventions. It is not uncommon for a retail environment to combine modern cloud commerce with legacy warehouse systems. There, understanding Binary Numbers helps in the correct technical specification and in controlling edge cases before they turn into financial deviations.
The first common scenario is inventory. If a warehouse field is incorrectly defined as a small signed range, a large quantity can exceed the allowed limit and lead to overflow. The result can be negative stock, hidden products, failed marketplace updates, or overselling. For businesses with B2B orders, large batches, or multiple warehouses, inventory management should be designed with room for growth, not based on today’s smaller scale.
The second scenario is prices and amounts. Many serious systems avoid floating point calculations for money and store amounts in cents, i.e. 19.99 euros as 1999 cents. This approach reduces rounding errors, but requires proper choice of integer type. In international e-commerce with different currencies, high order values, discounts, taxes, and refunds, fixed-point arithmetic must be clearly defined at the architectural level.
The third scenario is IDs. An e-shop starting with a few thousand products may never imagine millions of records in orders, order lines, logs, sessions or analytics events. But growth, automation and integrations quickly increase the volume. MySQL integer types, for example, have different storage sizes: TINYINT 1 byte, SMALLINT 2 bytes, MEDIUMINT 3 bytes, INT 4 bytes and BIGINT 8 bytes. The choice should be made based on anticipated scale, storage costs and future migration risk.
The graph below shows the difference in storage size of the basic MySQL integer types. For a small e-shop the difference may seem insignificant, but in tables with hundreds of millions of logs or events it affects indexes, speed and infrastructure cost.
Source: MySQL 8.4 Reference Manual, Numeric Type Storage Requirements
The fourth scenario is APIs. In an API integration, the schema must clearly state whether a field accepts negative values, what the maximum limit is, and how the system will react to out-of-bounds data. A quantity field must not simply be “number.” It must have rules: integer, non-negative, maximum expected value, validation error, retry policy, and logging. Similarly, an adjustment field can be signed, because it must express positive and negative movements.
The fifth scenario is reporting. If the numbers are corrupted in the database or middleware, the dashboard may show «correctly formatted» but incorrect data. This is dangerous, because decisions about purchasing, pricing, performance marketing and cash flow are based on reports. A technical error in data types can result in the wrong business decision.
The first step is to map numeric fields. Ask your technical team or agency to map all critical numeric fields: product ID, customer ID, order ID, stock, reserved stock, price, tax, discount, shipping cost, refund amount, loyalty points, coupon usage counters, and accounting adjustments. For each field, it should be clear whether negative values are allowed and what the maximum expected value is over a three- or five-year horizon.
The second step is data type mapping. Fields that cannot be negative, such as IDs and counters, can often be unsigned where the database supports it. Fields with accounting corrections need signed types. Monetary amounts must be treated with special care: either with decimal precision types or with integer values in a smaller currency unit, always with clear documentation. Here, knowledge of signed binary numbers and unsigned binary numbers does not replace the developer, but helps the entrepreneur to check if the solution is mature.
The third step is validation at the boundaries. Each critical field should be tested not only with «normal» values, but also with edge cases: 0, 1, maximum allowed value, value above the limit, negative value where not allowed, too long order ID and refund larger than the original transaction. These tests should be in place before launch, migration, Black Friday, connecting a new ERP or changing payment provider.
The fourth step is to document your APIs. Each endpoint should describe the numeric constraints. For example: “stock_quantity: unsigned integer, minimum 0, maximum 4,294,967,295” or “inventory_adjustment: signed integer, minimum -100000, maximum 100000”. This clarity reduces support costs and prevents errors when changing partners, developers or platforms.
The fifth step is monitoring. Set up alerts for negative inventory, unusually large IDs, failed imports, overflow errors, rejected webhooks, and discrepancies between e-shop and ERP. Binary Numbers don’t show up in the merchant dashboard, but symptoms of incorrect numeric limits show up in canceled orders, fulfillment delays, and customer tickets.
The graph below shows how many decimal places are needed to express the maximum unsigned value at basic bit depths. It is a simple way to visualize how quickly capacity increases when bit depth is doubled.
Source: Calculation from the formula 2^n – 1 for 8, 16, 32 and 64 bits
The value of the DesignNews article lies not only in the technical explanation of the binary system. It lies in the fact that it reminds us that computers do not «understand» numbers like humans do. They interpret bits based on rules. If these rules are not common to all systems in an e-shop, then the commercial operation is built on tacit assumptions. And tacit assumptions are often the root of the most difficult bugs.
For an e-commerce store owner, the right approach is to treat numerical data as a critical asset. Prices, inventory, IDs, returns, and accounting transactions should have clear boundaries, correct data types, documented APIs, and tested edge cases. The more an e-commerce store grows, the more technical detail turns into business resilience.
Binary Numbers may live at the lowest level of technology, but their implications extend all the way to the checkout, the warehouse, the customer experience, and the credibility of the brand. Understanding the difference between signed and unsigned is not an IT course for experts; it is a practical tool for any e-commerce business that wants to scale without carrying hidden technical debt into the future.
Sources: DesignNews – Unsigned vs Signed Binary Numbers, Part 2, MySQL 8.4 Reference Manual – Numeric Type Storage Requirements, Two's Complement – Wikipedia, Integer Overflow – Wikipedia, Signed Number Representations – Wikipedia
Unsigned binary numbers are sequences of bits that express only positive numbers, while signed binary numbers can also express negative numbers using the two's complement representation.
The difference between signed and unsigned binary numbers is critical for e-shops because it affects the interpretation of numbers such as prices, stocks, and IDs. Choosing the wrong one can lead to errors such as negative stocks or incorrect charges.
Binary numbers define how values and amounts are stored and calculated. Incorrect data types can cause rounding errors or overflow, especially in international e-commerce with different currencies.
Incorrect use of binary numbers in APIs can lead to negative values where they are not allowed, causing errors in data transfer and inaccuracies in reporting.
List all critical numeric fields and confirm that each field has the correct data type (signed or unsigned) and appropriate limits, based on your business reality.
Key scenarios include inventory, pricing, IDs, API integrations, and reporting. In any case, mishandling binary numbers can lead to errors and financial discrepancies.
Documenting APIs around binary numbers ensures that numeric field constraints are clear, reducing support costs and preventing errors when switching partners or platforms.
