I don't have any examples to point to. In truth, many of these screens may be hard to find on the web for the simple fact that most of them tend to be "ugly". These kinds of screens are rarely pretty.
I can offer some tips, from long history working with these things.
Consistency. Make everything "work the same", and work the same all the time. Basically, you should be able to do your entry looking at the form, not the screen. All those flashes and subtotals and colors are nice after they keyed the form in, but not during entry itself. There you basically need audio alerts to let them know "something is wrong". The classic "ticky-ticky-ticky-ticky-beep-beep-beep-beep" scenario as the user discovers that they entered a field wrong 4 fields back. The users aren't quite blind, but they're not going to be looking at your screen. The data is on the form.
It's better to work modally, and STOP THEM for ERRORs than let them keep going. For large forms, scanning all of that information and looking for errors after the fact is very difficult. Stop them when they're wrong so they can fix it and move forward rather than coming back to fix it at the end. The more business rules and validation and enforcement you can have on the form, the better. Popups, alerts, pickers, if it needs their attention, modal modal modal. They're not working with clay here. They're not authoring the great american novel or modeling the global economy.
Summarize the results for spot checks. For example, keying in an order, they should be able to look at the order total and line item count to see if they got the order in "correctly" as a sort of checksum rather than having to scan their entry field by field. Most workflows have an inevitable cross check phase where they go through their entry to verify the data, but that should be after the "raw keying" of the data. People work faster when they're in a "bulk entry" mode rather than spot checking each one, each time they key it in. It's breaks their rhythm. Make detecting and correcting the exceptions easier after basic validation and keying is done. If some fields are more important than others (and you know which ones those are), visually highlighting them on the screen AND on the paper form works wonders.
If the forms and such are designed well (both the computer forms and the paper entry forms), errors should be difficult to enter (like the wrong customer, or wrong item, etc.). You might have a typo in some notes or special instructions, but, not so much everywhere else. If they miskey an item or amount, odds are the order won't total properly so the simple checksum will help them catch it.
Going back to "consistency", make sure things like pickers and such all operate the same. Try to keep the special functions to a minimum, as it simplifies training and lets users just "flow" in to their work.
Keyboard shortcuts and navigation are a requirement, not an option. A real pain point here can be detail areas (i.e. table structures). You may need a shortcut to enter and exit the table strcutures. You may have seen a lot of examples where you can "Tab" in to the table, but not tab back out. Have a dedicated "meta-tab" key to move in and out of sections. Requiring the mouse to navigate out of a section is a no no.
Have a single hot key for pickers. Ideally, they won't have to use these too often. Maybe for customer lookup, most of the other codes they're inevitably memorize or they'll be keyed on the entry form. Make the pickers filterable.
Scrolling is the devil. Scrolling is evil. No Scrolling! Paging better than scrolling because "fields don't move", they're always "in the same spot" on the screen. How often have you "scrolled" and had to search to pick up "where you started" before the scroll to regain context. Even for pick lists paging works very well because the page change lets them know they actually "did something" visually. Many times you scroll a row and "gee did I really?" Single line scrolling can be too subtle. For large entry forms, multi-pages beats long, scrolling treatises every day of the week. If your forms are that big, make sure you have a hot key to move forward and backwards through the form, and make sure there is some context information on each page (customer name, order number, whatever...simple header).
Robust querying. "Query by example" as it's known is one of the best mechanisms (i.e. they fill it the form "what they know" and forms come back). Folks need to find data by just crazy criteria, if most every field is queryable, this lets them do that without you second guessing what they will or won't need. Informix 4GL used to have a spectacular QBE system (> 04/01/09 for dates after Apr 1 2009, 12345|23456 for item codes 12345 or 23456). A good QBE expression will most likely not validate in a typical field, it's a special case. (Which is why you rarely see QBE today, it takes too much work -- but it is OH so nice.)
Remember, users don't know WHY or HOW they do things, they only know WHAT to do. They know "when I want to do A, I hit key Y" they don't know WHY it's Y, where Y is located, the keys X an Z might do similar things to A because they're grouped together. No, they don't know your command taxonomy. They don't know your abstractions. They know to do A, hit Y. Want to Bold a word? Type Ctrl-B. Maybe Ctrl-I to italicize a word is obvious to you because of the mnemonic, it's not to most users. Maybe the Ctrl-B and Ctrl-I are on the Format menu, nicely grouped. Doesn't matter. Ctrl-B == Bold, how do I do Italics?
The downside of these interfaces is training. They do take training in order for them to be used. But, in truth, for any reasonably complicated business, the user is going to need training on far more than just the keying process anyway. The entry screen isn't going to teach them the business policies, business rules, etc. You can enforce these in the application, but the user is going to need to know them on their own anyway.
But that's OK, because in the long run it's simply more efficient. The game here is getting the data from the user efficiently and presenting it to them in a consistent way. I won't say "logical" way, as, while logic may be logic, it may not be the users logic. So, you can be logical if you want, call it what you want, but be consistent to your users.
Another anecdote, we used to 10 key return data. This tended to be just lists of number, like an item code and a quantity. For our purposes it's faster to simply have the users key this data twice in a row than anything else. It catches typos, transpositions, etc. Combined with batch checksums makes the keying go that much faster. These guys only looked at the screens when they started, when they finished, and if they got an error.
Finally, no matter what, your screens and procedures WILL change. Whatever form you're using this year, will change next year. That's just reality, so, FYI, be ready for it.
Good luck with your project.