Assuming the Update database action occurs outside (and after) Increment Row, as in the following:
Then the fact that the orange flow may occur before Increment should has no effect on the end result. This is because composite data elements (database records and other data structures) are handled by reference, so while Increment Row's exit may receive a reference to the API Econ structure before EP has been incremented, the Increment Row process will not end (and as a result, processes depending on it such as the update, will not begin), before the EP element in the same reference is incremented.
You can check this out by tracing all of this, and checking EP's value after exiting Increment Row (i.e. on the flow originating in the Increment Row's exit, or any subsequent flows).
Note that if the Update is included in the Increment Row, as in the following screenshot:
Then since both Update and Increment depend on (= have incoming flows from) API Econ, one will execute just before the other (the exact order between the two actually depends on which was added first to the model), but you can be sure, that Update executes before the incremented value goes back to API Econ.
BTW, aside from taking Update outside the Increment Row process, as demonstrated in my first screenshot, you can also workaround this, by implementing the following, avoiding the API Econ<->Increment loop which is at the heart of the issue:
Finally, I should point out that unless you explicitly defined it otherwise (via the primaryKey property), the EP field, being the first field in the API Econ database record, will be defined as a primary key, which means that update will probably fail, unless the database already contains a record with the incremented EP value.
For best results, use the Firefox browser..