Price book amounts: 5 checks before you save a price

• Enter every amount in the smallest unit of its currency: cents for US dollars, and one yen for JPY.
• Use a positive whole number with no decimal point and no formatting characters.
• Check each amount against the valid minimum for the country on the account's location.
• Confirm the entry form for each currency in the documentation of the software you load into.
• Compare sample Stripe invoice amounts with the saved prices, because fractional invoice amounts are rounded to the nearest multiple of 100.

Square's developer guide shows what can go wrong with the form of an amount. It says that "When working with the Money object, applications might get an EXPECTED_INTEGER error code because the specified amount value is invalid." Finding a bad amount before it reaches the software is simpler than reading an error code afterward.

The checks below cover the amount field itself. They do not tell you what a job should cost, because those decisions stay with you. Each check is one you can repeat on every line.

Workiz makes a related point about scale in its plumbing flat rate price book guide : "Managing a manual price book becomes impossible when scaling a fleet of 5 to 50 technicians." That statement is Workiz's, and it is about a fleet of that size. The five checks are written so you can run them on a short list or a long one.

Each section below gives the rule, its source and the reason it matters. The checklist at the end puts the five checks in the order you would run them. You can read the sections in order the first time through, then use the checklist as the working version for each load.

Enter each amount in the smallest unit of its currency, which for US dollars is cents, not the dollar figure you would write on a quote.

Square's guide to monetary amounts says: "Make sure the amount value is specified in the smallest denomination of the currency used." It gives this example: "For example, the smallest currency denomination for USD is cents." Under that guidance, a price written with a decimal point in dollars is entered as its cent value, with the decimal point left out. The amount field takes the cent figure, so the decimal point does not go in.

Currencies do not all work the same way. The same guide says, "That is, the smallest unit of the currency is ¥1 (1 JPY)." For yen, then, the smallest unit is one yen, and a price in yen is entered as a count of yen. Dollars and yen are entered differently, so the currency has to be part of every check.

Here is how the cent rule works on a few lines. A price written with cents is entered with the cents included and the decimal point removed. A price written as whole dollars is entered with its cents place filled with zeros. A price with a thousands separator, such as a comma, has the separator removed as well. Each line keeps the same total value, only in the smallest unit.

Illustrative example: 5 dollars and 500 yen

A line priced at 5 US dollars is entered as 500, the number of cents, with no decimal point. A line priced at 500 yen is entered as 500, because the smallest unit of yen is one yen. Both entries are positive whole numbers, so only the currency column tells the reader which unit applies. Check the minimum for the account's country before you save either line.

A practical habit follows from this. Put the currency code next to every amount in your price book, in its own column if you can. A reader who sees only a bare number cannot tell whether it means whole dollars, cents, or some other unit. With the currency beside it, the unit is clear to any reader. If you are setting up the fields for this, see setting up price book inputs .

When you copy from the price book into billing or payment software, check how that software describes the amount field before you load. The field label, the help text, or the documentation for the software may say what unit it expects. Do not assume the unit from the label of your own price book column, because the two may not use the same unit. If the software's documentation is unclear, test one line first and compare the result with the price you meant to save.

Keep the unit fixed for the whole sheet when you can. If one part of the list uses dollars and another uses cents, the load can be correct for one part and wrong for the other, and the sheet will look consistent to a reader who does not check the unit. Convert the sheet once, then check a sample of lines against the original prices before you load anything.

Use a positive whole number with no decimal point, because Square's guide says the amount value must be a positive integer.

The guide states: "Make sure the amount value is specified as a positive integer." So a decimal point or a value that is not a whole number in the amount field is the kind of problem to check for before loading.

Spreadsheets can cause this problem. A cell can show a whole number while its underlying value has decimals, depending on how the cell is formatted. Before you export, check the raw value in each cell that feeds the amount column, not only the display. If your export adds formatting such as a dollar sign or a comma, remove it so the field holds only digits. For the layout of a sheet like this, see the parts pricing spreadsheet fields for repair quotes .

After the cleanup, sort the amount column from smallest to largest and read the top and bottom rows. A value with a stray character or a misplaced decimal point may stand out at one end of the sort. Then count the lines in the sheet and compare that count with the number of prices you expected to load. A difference is a reason to look again before you proceed.

Negative values fall outside the rule as written. The guide asks for a positive integer, so any line that is zero, negative, or blank should be reviewed by hand before it is loaded. Treat any line that fails the form check as an open item. Mark it, fix it in the sheet, and check it again before the load. Do not let it pass because the rest of the sheet looks right.

A blank line in a price book is easy to miss on a long list. A quick filter for empty or non-numeric amount cells is one way to find those lines for review.

Make sure each amount is greater than or equal to the valid minimum, and remember that under Square's rule the minimum depends on the country tied to the account's location.

The guide says: "Make sure the amount value is greater than, or equal to, the valid minimum amount." It then adds: "Valid minimums are determined by the Location.country associated with the account." So for Square, the valid minimum is determined by the country on the location linked to the account, and that is the country to check against.

This post does not list minimum values, and you should not rely on a number from memory or from a colleague. Look up the current minimum for your account's country in Square's documentation before you load a low price. If your price book has low prices, such as add-on fees or small service charges, check those lines against the minimum before the rest.

Record the country for the account next to the price book, along with the date you looked up the minimum. A note with a date tells the next reader when the number was last confirmed, which matters if the minimum is looked up again later.

When a line fails this check, you have two choices. You can raise the price to the valid minimum, which is a pricing decision and yours to make, or you can remove the line from the load and handle it another way. Either choice should be written down in the price book so the next person does not have to guess why the line is missing.

Do not assume every currency uses cents, because Stripe's examples show that the amount value depends on the currency: 500 JPY is entered as 500, 5 ISK is entered as 500, and 5 UGX is entered as 500.

Stripe's supported currencies page gives these examples: "For example, to charge 500 JPY, provide an amount value of 500." "For example, to charge 5 ISK, provide an amount value of 500." "For example, to charge 5 UGX, provide an amount value of 500." Read them as examples for those three currencies. They do not show how every currency is entered, and they should not be used to infer a rule for a currency that is not listed.

The practical lesson is to look up each currency you use. Do not carry the dollar habit into every row. A price in one currency can be entered in a different form from a price in another, so check the documentation for each currency on your list.

The Square guide's yen statement points the same way. Its smallest unit for yen is ¥1, which matches the Stripe example for 500 JPY. Once you have confirmed the unit for each currency, record it in a short reference list at the top of the price book. Then anyone who adds a line can see which form applies to it.

When a new currency is added to the price book, repeat the lookup before any line in that currency is loaded. Do not copy the entry form from a line in a different currency, even one that looks similar. A short note of the lookup date beside each currency makes the list easier to review later, and it shows which lines were checked against which documentation.

In Stripe, an invoice amount that is fractional after prorations, coupons, or taxes is rounded automatically to the nearest number evenly divisible by 100.

Stripe's currencies page says: "For invoices where the amount is fractional after prorations, coupons, or taxes, Stripe automatically rounds that amount to the nearest number evenly divisible by 100." The rule is about invoices, and it applies to amounts that are fractional after those three steps. The quote does not say how a price saved in a price book will be treated, so do not assume the same rounding applies to the saved value.

For a manager, this means the invoice total may not match the price you entered. For more on how totals are built, see invoice total calculation and rounding limits . If your price book is loaded into an invoicing flow that uses proration, coupons, or tax, compare a few resulting invoice amounts with the prices you saved. Write down any difference you find and where it came from, so it can be explained later without reconstructing the sheet. Include the original price, the saved amount, the invoice amount, and the reason for any adjustment, such as a proration, a coupon, or a tax line. With those four pieces in one row, the difference can be traced without guessing.

Keep the rounding question separate from the entry question. Rounding is about what happens to an amount after it is used in an invoice. The unit, whole-number, minimum, and currency checks are about the value you save in the price book. Both matter, but they are different problems, and a fix for one does not solve the other.

Run all five checks on every line before you save or load a price, and keep a record of the result for each line you change.

Use this order, which follows the sections above:

1. Unit: confirm the currency for the line, and enter the amount in the smallest unit of that currency. For US dollars, that is cents. For yen, Square's guide gives ¥1 as the smallest unit.
2. Form: confirm the amount is a positive whole number with no decimal point and no formatting characters.
3. Minimum: for a Square account, confirm the amount is greater than or equal to the valid minimum for the country on the account's location, using Square's current documentation.
4. Currency scale: confirm the entry form for the currency against the documentation for the software the load goes into (Stripe's supported currencies page for Stripe, Square's monetary amounts guide for Square), and do not reuse a rule from another currency.
5. Rounding: for Stripe invoices, compare a sample of resulting invoice amounts with the saved prices, and note any amount that is fractional after prorations, coupons, or taxes.

Work through the list in this order, because the first check changes the value the later checks read. A line with the wrong unit can pass a whole-number test and still be wrong. Once the unit is right, the form check is the next step, and then the minimum.

Save a copy of the price book before each load, so you can compare the loaded values with the sheet if an error appears. Keep the copy with the date and the software version you loaded into, if your team records those. A dated copy makes it easier to explain a difference later.

Finally, name one person to sign off on the checks for each load. A single named reviewer makes it clear who ran the checks and who answers for the result.

After each load, compare a sample of the loaded prices with the saved sheet, and record what you found. If a line did not load as expected, correct the sheet first, then load that line again rather than editing the software by hand. A corrected sheet keeps the price book and the billing software in step, so the next load starts from the right values.

Next step today: pick five lines from your price book, write the currency beside each one, and run the five checks on them before you change the rest of the sheet.

Does a price book amount include a decimal point?

No. Square's guide says the amount value must be a positive integer, so leave the decimal point out and enter the cent figure for USD.

Do all currencies use cents?

No. The amount value depends on the currency, so look up the entry form for each currency you use.

Does the minimum amount depend on the country?

For Square, yes: the valid minimum is determined by the country associated with the account's location.