Bank of Israel Exchange Rates: Automated Pricing for an Importing Business

The Bank of Israel publishes representative rates on two programmatic routes: a simple endpoint returning the current rate for every currency, and the EDGE series database returning a historical series by code. Import pricing needs both - one for the daily refresh, the other to explain a price after the fact.

The two routes, and when to use each

In the test we ran, the simple endpoint returned 14 currencies: US dollar, euro, pound sterling, yen, Swiss franc, Canadian and Australian dollars, Danish, Norwegian and Swedish krone, South African rand, Jordanian dinar, Lebanese pound and Egyptian pound. If the currency you import in is not on that list, that is a decision to make up front rather than discover in production.

What does a response contain, and why does the unit field break calculations?

Each item in the simple route's response carries the currency code, the rate, a unit field and a percentage change, plus one lastUpdate timestamp shared across the whole collection. The unit field is the trap: it is not always 1.

In our test the Japanese yen came back at 1.9227 with a unit of 100 - meaning the value refers to 100 yen, not one. The Lebanese pound came back with a unit of 10. Code that multiplies an amount by the rate without dividing by the unit is wrong by a factor of a hundred, in precisely the currency where that is hardest to notice by eye.

Two practical consequences:

• Store the rate and the unit as two separate fields, never their quotient.
• Route every conversion through one function taking amount, currency and date, rather than scattered manual multiplication.

Which rate do you actually need - today's, or the one in force then?

It depends on what the line does. A quote to a customer needs a current rate, because it is forward-looking. A supplier invoice received two months ago needs the rate in force on that day, or the recorded amount cannot be explained.

So the correct separation is between a live rate and a locked rate:

1. The live rate is fetched automatically and used only for display and for computing a new quote.
2. The locked rate is written onto the document at creation, together with the date it came from and the unit.
3. Regenerating a document uses its locked rate, and does not fetch a fresh one because somebody pressed print.
4. A rate change does not update existing documents. It creates a new version, if a new version is wanted.
5. A historical report reads the stored fields rather than re-fetching from the source.

The same principle of freezing a value onto the document appears in keeping one source of truth for price lists and quotes.

The separation sounds obvious until you look at what happens without it. A system recomputing every amount from the current rate shows a quote sent in January at a different total in March, and the salesperson opening it in front of the customer cannot tell which number is right. Once the rate is locked onto the document, "why did it come out like that" is answered by three stored fields rather than by reconstruction. In a business that also runs recurring contracts the same question returns at every renewal - see contract renewal reminder control.

What a daily fetch that breaks nobody looks like

A good daily fetch is a few lines of code and three decisions. The code requests the current collection, writes one row per currency carrying the rate, the unit and the publication date, and does not overwrite an existing row for the same date. The decisions are when it runs, what happens when the response is identical to yesterday, and who is told when no response arrived at all.

• Frequency. Once a day suits most businesses, preferably after the publication hour rather than at midnight.
• No change. A response identical to yesterday is not an error. Store it as the same publication, not as a new day.
• Silent failure. A fetch that failed and wrote nothing looks exactly like a day with no publication. Separate "no publication" from "we could not fetch" into two distinct statuses.
• Historical load. For the initial load, use the series database with a date range and run it once. There is no reason to re-fetch 2019 every morning.

What actually breaks in import pricing

• A day with no rate. Weekends, holidays and non-publication days leave a hole in the series. A fetch expecting a daily value needs an explicit rule: take the last publication preceding the date, and record which date was actually used.
• Time zone. The update timestamp arrives in UTC. A system tagging it as local time shifts a morning publication into the previous day.
• Rounding. Rounding at every intermediate step instead of at the last one produces agora-level differences that accumulate across many order lines.
• Double conversion. An amount converted to shekels, stored, then converted back for display almost never returns to the original number.
• Representative rate versus actual rate. The published rate is not the rate at which your commercial bank actually converted your money. That difference shows up in bank reconciliation, not in pricing.

That last gap ties directly into cost allocation on imports, covered in landed cost allocation control for an importer.

What to have ready before connecting

• The list of currencies the business genuinely trades in, checked against the list the source publishes.
• A decision on what "today's rate" means in your business, including what happens on a non-publication day.
• Fields on the document for rate, unit and rate date - three fields, not one.
• Somewhere to keep the raw fetch response, at least briefly, for investigation.
• A rule on who may override a rate manually, and where that is recorded.

Sources

• Representative exchange rates - Bank of Israel public endpoint
• Extracting representative exchange rates from the new series database - Bank of Israel